GDA: Status

Derek Atkins warlord at MIT.EDU
Wed Jun 4 09:47:30 EDT 2008

Phil Longstaff <plongstaff at> writes:

> Derek Atkins wrote:
>> Phil Longstaff <plongstaff at> writes:
>>>> 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).
>> Is that the only individuality?  Or are there others as well?
>> Could we abstract those pieces out ourselves?
>> How do other projects using those technologies handle that?
> I took a look at a few projects using libdbi.  They seem to have some
> external mechanism (script) to create the db, and they also seem to have
> more of a permanent database idea (e.g. a reference database, a library
> contents database).

MythTV has support for both MySQL and PG and does database
creation and upgrades in both underlying DBs.  So there's clearly
a way to have mostly-common SQL.

> Well, as long as queries and data modification stick to standard sql, gc
> could be ok.  Note that there are some things which, whether standard
> sql or not, I would like to use if available e.g. the ability to insert
> multiple rows at a time (for slots) which is not supported by sqlite.

If it's not supported by SQLite then how do you do it?  Or are you
saying that GDA is smart enough to split up multiple rows into
multiple statements when using the SQLite backend?

> We could abstract out the pieces.  What I have written could be adapted.
>  It's simply a question of risk.  I'm not so tied to libgda that I
> couldn't switch, even now.

True, which is why I'm asking these questions.  I think depending on
GDA right now is a HUGE risk because it seems like such a moving
target.  I think using DBI is lower risk in terms of stability but
perhaps higher risk in getting lots of DB support (because it doesn't
abstract the tables and query language).

> Phil


       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL:    PP-ASEL-IA     N1NWH
       warlord at MIT.EDU                        PGP key available

More information about the gnucash-devel mailing list