Replacement for libdbi

[John Ralls]

On Jan 11, 2014, at 12:51 PM, Phil Longstaff <phil.longstaff at gmail.com> wrote:

> When I first started the sql backend, I worked with gnome-db (http://www.gnome-db.org/) aka libgda.  This is a gobject-based database access technology.  I started working with version 3.X and ran into some bugs and missing capabilities.  The gnome-db project had moved on to developing 4.X, but when I tried to use it, I also found bugs/missing features.  That's the main reason there is a backend-sql which forms the "base class", with backend-dbi forming the "derived class" which has the actual technology used.  There used to be a backend-gda.
> 
> There was one guy who wanted to rewrite gnucash (this was 2007?  2008?) using libgda as the core technology.  At the time, this would have required a compete rewrite and we told him it wasn't going to happen.  In any case, it's another potential solution.  The homepage says the current version is 5.2.1.  I don't know what version any particular distro has.
> 
> I suppose QtSql (http://qt-project.org/doc/qt-4.8/qtsql.html) is another potential solution.

Phil,

You’ve perhaps missed out that we’ve decided to move away from the Gtk universe and embrace C++. That pretty much rules out libgda. 

QtSqlDatabase is an option, but it’s one I’d like to defer until we’re ready to redo the GUI, which I don’t think can happen in this dev cycle. Qt is an enormous dependency and I’d like to not go back to depending on both Gtk and Qt (which we did in 2.2 in order to have AQBanking), though I guess it’s worth debating whether that’s worse than forking another project into our repo or dealing with a dependency that isn’t supported by the distros.

Regards,
John Ralls 

> 
> Phil
> 
> 
> On Sat, Jan 11, 2014 at 1:53 PM, John Ralls <jralls at ceridwen.us> 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
>