GDA: Status

Derek Atkins warlord at MIT.EDU
Mon May 26 17:04:39 EDT 2008

Can't you just use "CREATE IF NOT EXIST" ?  Or is that not portable enough
across various SQL implementations?

Part of me is really thinking that GDA is more trouble than it's worth.
I'm sure Esodan will vociferously argue against this, but perhaps we
should drop GDA and choose something that actually works?


Quoting Phil Longstaff <plongstaff at>:

> Graham Leggett wrote:
>> Phil Longstaff wrote:
>>> Well, V4 basically works with the sqlite provider.  There were a number
>>> of memory leaks and other small issues.  However, there are a number of
>>> problems with the V4 mysql provider - it's not ready for use.
>>> I've decided to switch back to V3 for now.  I'll continue to supply
>>> patches and if I have to, I'll pull it into the tree under 'lib'.
>> Considering that V3 is not being actively developed, and that bugfixes
>> to v3 won't be accepted, is it not safer to develop for V4, and get the
>> upstream project to fix any problems involved? How far away is the V4
>> mysql provider?
> I don't know how far away the V4 provider is.  They have a
> meta-information system which allows you to access info about the db
> structure (e.g. which tables exist) and the meta-information system has
> been redesigned for V4.  It hasn't been implemented for mysql yet, so
> when gc starts, it tries to create all of the tables, even if they
> already exist.  Note that it was a meta-information bug which was
> causing a problem in the gc-V3 code which was not accepted.  The bug is
> that if you delete all db tables and then ask libgda to update the
> meta-information, it still thinks that the 2nd table exists (usually,
> billterms) so that it won't be created.  This could happen when you are
> trying to save-as to a db, so billterms won't be saved, and lots of
> business objects will be screwed up.
> I see 3 possibilities:
> 1) Do libgda V3 maintenance ourselves by sending in patches and asking
> for them to be applied.  For the particular bug I found, I didn't send
> in a patch, but asked for the bug to be fixed.  Maybe they won't fix
> bugs but will apply patches.  They would probably not create new
> tarballs, so anyone who wanted to use gc-libgda would need to check out
> the V3 trunk from svn and build from source.
> 2) Pull the libgda-V3 branch into the gc tree under lib.  The GC team
> would maintain it.  This has the advantage that it would not be an
> external dependency any longer, so anyone who wanted to try the gda
> backend could.  The obvious disadvantage is a mess of code that nobody
> knows but that we need to maintain.  Once libgda-V4 is further along, I
> can switch back to V4.
> 3) Change my decision and switch back to V4.  I have basic operation
> with sqlite working.  There is at least 1 regression (I can't create the
> index on the slots table) which would have performance implications.  I
> don't know where the problem with index creation is.  However, there are
> some improvements.  The libgda-V4 statement structures can represent SQL
> operations which were not possible in V3, and which would improve
> performance.  However, as I said above, the mysql provider is missing
> some major functionality.  I don't know about postgresql.
> There are other issues with the whole gda backend which I need to work
> on and which are independent of which version of libgda is used:
> 1) some of the dialogs (e.g. price editor) create an object when the
> dialog is opened and then modify it as the dialog is used.  This can
> cause commit requests for objects which break db constraints (a price
> must have a commodity, but a save request may come before the commodity
> is set).  Fixing this requires a change to db logic to only create the
> object when 'OK' is pressed.
> 2) versions for tables and handling of version updates
> I had decided to stay with V3 because it would not be a step backwards
> in functionality.  I wanted to try V4 to see what shape it was in, to
> get some experience with it, and to provide some feedback to the
> developers before they release.
> I think I'll stay with V3 for now and monitor V4.  When they implement
> the V4 mysql meta-info code, I'll reconsider switching.  I'll also do a
> bit of testing to see how postgresql looks.
> Phil
> _______________________________________________
> gnucash-devel mailing list
> gnucash-devel at

       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL:    PP-ASEL-IA     N1NWH
       warlord at MIT.EDU                        PGP key available

More information about the gnucash-devel mailing list