Replacement for libdbi

[Geert Janssens]

John,

ODB looks promising. If distro packagers are willing to package it (Debian's Sébastien Villemot 
seemed ok with it already provided it can be packaged) that would be the best candidate IMO.

I checked cross-platform availability as well. OS X seems no problem. For Windows it mentions 
Mingw gcc 4.7 (Mingw64). I have been working on getting the Windows build compiling and 
running on gcc 4.8 and recently got some help with this from Gary Bilkus, so the version will 
be ok. I'm slightly worried about the mingw64 part. Our build system is mingw32 so we should 
check that is supported as well. If not we will have to evaluate if we can switch to mingw64 
instead. Unfortunately the mingw32 team seems rather hostile to anything not mingw32, so I 
probably won't get much help from their side.

I haven't checked the other options yet. Given the potential of ODB I'm in favour of evaluating 
that one completely first and only look at other options if it turns out ODB can't be used at all 
for some reason.

Geert

On Saturday 11 January 2014 10:53:48 John Ralls wrote:
> I'd like to replace libdbi because they refused to change their use of
> time_t to avoid the 2038 bug, insisting that since *BSD use a 64-bit
> time_t, it's not a problem [1]. Furthermore, transactions are
> supported only in their new 0.9.0 version which isn't available yet
> in the major distros.
> 
> Unfortunately, neither are any of the other potential solutions. ODB
> [2], which I find particularly impressive, is supported on Fedora,
> but not Debian/Ubuntu. AFAICT, Debian/Ubuntu package only libdbi and
> tntdb [3] for multi-db access libraries. Fedora has also approved
> SOCI [4], but apparently has not yet implemented the package.
> 
> There are some other solutions out there, but they either require
> compiling the backends into the main binary (OTL [5]) or they aren't
> flexible about object-schema mapping (Debea [6]), which makes
> backward-compatibility with our existing database difficult.
> 
> FWIW, ODB does provide debs and rpms on their download page.
> 
> Boost unfortunately does not provide a sql-abstraction library.
> 
> Rather than depending on one of these libraries, we could fork one
> into our own repository; if we did that with libdbi, we could even
> fix the time_t problem.
> 
> Thoughts?
> 
> Regards,
> John Ralls
> 
> [1] http://sourceforge.net/p/libdbi/bugs/15/
> [2] http://codesynthesis.com/products/odb/
> [3] http://www.tntnet.org/tntdb.html
> [4] http://soci.sourceforge.net/
> [5] http://otl.sourceforge.net/otl3_compile.htm
> [6] http://debea.net/trac
> _______________________________________________
> gnucash-devel mailing list
> gnucash-devel at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel