GDA: Status

Fri May 30 09:29:22 EDT 2008

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.

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?

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?

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.

-derek

"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