esodan at gmail.com
Sat May 31 17:05:01 EDT 2008
2008/5/30 Derek Atkins <warlord at mit.edu>:
> 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?
>>> 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.
>>>> gnucash-devel mailing list
>>>> gnucash-devel at gnucash.org
>>> 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
>> 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
More information about the gnucash-devel