GDA: Status

Sat May 31 17:05:01 EDT 2008

2008/5/30 Derek Atkins <warlord at mit.edu>:
> Daniel,
>
> My major concern here is that a year ago you were rallying for
> GDA and GdaQuery.  Phil threw out a bunch of his work to target
> GDA-3 with GdaQuery.  Now here we are, 6 or 9 months later, and
> the GDA team has moved on to GDA-4 already and are dropping GdaQuery,
> the very interface you were so adamant was the greatest thing
> since sliced bread.   Phil has found a number of apparently major
> bugs in GDA-3 which the GDA team seems reluctant to fix, and GDA-4
> isn't nearly as usable as GDA-3.
>

For now the GDA team is realy limited in developers. Vivien, the main
developer, concentrates its work on V4 witch is a major re-work of V3,
most of the work on V3 it's stopped becouse at the moment other
developers have no time enough to fix this bugs, I hope to they or
even me find the time to work around V3.

> So, what's Phil supposed to do?   Work with GDA-3 with the known
> bugs, knowing that those bugs will never be fixed?   Work with GDA-4
> which is just broken and cant be tested and hope that the GDA team
> gets it working and makes a release early enough that GnuCash can
> actually use it?
>

Fixing bugs on V3 is mainly done by some users/developers still using
it, I think any one have time enough to help to fix this bugs. GDA V4
helps to simplify most operations and create, execute and manipulate
SQL queries in a simply way.

> Or would it be more expedient to pick a technology that has a proven
> track record, proven stability, is NOT a moving target, and is
> already available in most distributions?
>

The developer must evalulate the alternatives and use it if he want
it. But ofcourse this desition will be affected over the time frame
you want to archive objectives.

I know that this is not new, but just need to evaluate the
alternatives, I realy don't know any thing about dbi, but why I think
GDA V4 is a good choice:

* It is based on GLib
* It will be propoused to be included on GNOME
* It's licended under LGPL
* As others, is a layer to have access to a different DBS using the same code
* As a GLib based library could be, more or less, easy to have
bindings to different languages
* V4, don't know V3, have XSLT transformations to access to data
* You can use virtual connections, have access to a tables in a
different DB as it was a local table; allows you, for example, copy
data from a table in a MySQL to a PostgreSQL database.
* And more..
* V3 has a more complicated set of objects, most of them removed for
simplicity in V4

> Why did the GDA team decide to drop GdaQuery?  And why did the
> move to GDA-4 break all the backends?  That seems like a very
> bad idea to me.
>

In V3 if you try to create "by hand" a Query, you must use a lot of
GObjects and properties to have a GdaQuery object, witch is realy
complicated way to describe or understand its parts. On version 4, you
have just a GObject called GdaStatement and a tree of C structures
describing the SQL query parts, in a realy simple way. To see a better
explanation about this look at GDA documentation (boulding from svn).

But there are a lot of API/ABI changes to get a more easy to use library.

> "Daniel Espinosa" <esodan at gmail.com> writes:
>
>> I've read all your other comments and is the same as before I "try" to
>> re-write most of the GC's core, you don't want to lesen the others,
>> the I don't plan to work on GC's as actualy is. If I can help Phil
>> improving GDA it's Ok. If some others work to modify the GC's core to
>> create a bussiness library and a GUI aplication I'll help. If the
>> bussiness library is written to sue a DB, using GDA or not, I'll help.
>>
>> And please Derek, don't reply this if you want to insult or vociferous.
>>
>> 2008/5/26 Derek Atkins <warlord at mit.edu>:
>>> 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?
>>>
>>> -derek
>>>
>>> Quoting 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.
>>>>
>>>> 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
>>>>
>>>
>>>
>>>
>>> --
>>>       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
>>>       Member, MIT Student Information Processing Board  (SIPB)
>>>       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
>>>       warlord at MIT.EDU                        PGP key available
>>>
>>> _______________________________________________
>>> 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)
>>
>>
>
> --
>       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
>       Member, MIT Student Information Processing Board  (SIPB)
>       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
>       warlord at MIT.EDU                        PGP key available
>

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