GDA: Status

[Phil Longstaff]

Derek Atkins wrote:
> 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?

If we stay with GDA-3, Daniel could provide fixes (or could commit
fixes), but there's no guarantee that there would be any more releases.
My suggestion to include GDA-3 in the GC tree was simply so that we
*could* guarantee and rely on GDA releases, namely, our own, and our
dependencies would then be on sqlite, mysql and pgsql libraries.  If or
when GDA-4 is solid enough and released or soon-to-be released, we could
switch to it.  It seems to me to be similar to some of the libraries
which lived under lib for awhile (e.g. goffice-0.0.4).

> 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?

One problem with libdbi is that its scope doesn't cover everything that
libgda's does.  From what I can tell, libdbi doesn't have any apis to
cover table/index creation, and that is one area that has a lot of
individuality (e.g. autoinc integer fields).

> 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.

>From an e-mail on the gnome-db developer mailing list:
On Wed, 2008-03-19 at 22:37 +0100, Vivien Malerba wrote:
> > After a long time, I'm pleased to announce the first version of Libgda
> > which will lead to a V4. This version is a major rework of the
> > library's internals to correct the conception errors that were made
> > with previous versions; it also aims at having a smaller yet more
> > powerfull and easier to understand API, and to close some long
> > standing bugs.
> >
> > A non detailled list of changes is:
> >  - Easier to understand and to use API, with less strange path usage
> >  - Reduce the size of the library (almost half the size and half the
symbols)
> >  - Easier connection opening (removal of the GdaClient object)
> >  - Merge of the GdaQuery and GdaCommand into only one object to
> > represent statements
> >  - New adaptative SQL parser (can be adaptated to each DBMS's SQL
syntax)
> >  - New database based dictionary which can handle namespaces
> >  - Rework of the database adaptators (providers) for easier
> > maintenance and more features
> >  - Sample "skeleton" database adaptators to make it easy to write a
> > database adaptator for a new
> >    database type
> >  - Updated documentation
> >
> > A few warnings however:
> >  - This is still an early version which probably has a lot of bugs and
> > as such it should not be used
> >    in a production environment.
> >  - Most of the database adaptators (providers) need to be re-written,
> > particularly MySQL (which is
> >    currently being done) and Oracle
> >  - Libgnomedb has not yet been updated and won't compile with this
version

One problem (which I just asked about on the gda list) is why GDA-3
isn't being maintained while GDA-4 is being worked on.

Phil