GDA: Status

[Daniel Espinosa]

2008/5/26 Phil Longstaff <plongstaff at rogers.com>:
> 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.
>

I just want to point that if you use V4 you may will get inmediatly
access to SQLite database, and after the API is stable enough the
other database providers will be on the road.

I don't think is a good idea to have a copy of GDA in GnuCash.

> 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 gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>



-- 
Trabajar, la mejor arma para tu superación
"de grano en grano, se hace la arena" (R) (entrámite, pero para los
cuates: LIBRE)