GDA: Status

[Phil Longstaff]

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