GDA: Status

[Derek Atkins]

Phil Longstaff <plongstaff at rogers.com> writes:

> My memory is that I chose GDA over DBI because DBI did not seem to be
> maintained.  In fact, there is nothing on their page re release between
> Nov 2005 and Feb 2007 (I remember starting the project in 2006).  What
> we are now finding is that GDA-3 will not be maintained (I don't have
> any current issues with it, but if I find one, who knows how it might
> get fixed in the field).  So, with GDA, I think we have GDA-3 which has
> no maintenance (and may not be on all distros) and GDA-4 which won't be
> released for another 9 months.

Yeah, their web site certainly isn't maintained, but the project
is very mature so doesn't require much work.  But they certainly
have made new point releases in the interim.

> Moving to DBI would require:
> 1) a procedure to create a new db.  As Albert Lash mentioned, perhaps
> support for building sqlite tables could be built-in and external
> procedures could be used to build mysql/postgres tables.  I'm not sure
> how table upgrades because of new columns would be handled.  Perhaps by
> the time we need upgrades, GDA will be out in the wild and we could look
> at whether to move back.

My appologies for sounding like a broken record, but if you look at
MythTV they show how to support both MySQL and PG in an automated
fashion.  At least I'm pretty sure they can create and update tables
for both DBs.

We should have a plan in place at day 1 for how we'd deal with this.
I DO like the MythTV model where we have a DB Schema Version number
in a known table/location and then we can use that to detect whether
we need updates.

Then the only question I see would be forming the correct SQL
statement for the correct DB to do the update.  Even then I would
suspect it would FAIRLY similar on all DBs, no?  For example, SQLite
only supports ADD COLUMN and RENAME TABLE support in ALTER TABLE.

> 2) potentially, an abstraction internal for each db driver just to
> handle any differences for each db.

I suspect we might need this, yes.  I just don't know how expensive
this will be.

> 3) a new url format.  For sqlite, not a problem, but would be needed for
> mysql/postgres.

Why would we need a new URL format?   Anyways, I wouldn't consider
this a major issue.

> 4) switch gda calls to dbi calls
> 5) lots more.

"think you should be more explicit here in step two"  (okay, step 5).
What's "lots more" here?

> I think what I want to do is create a dbi backend in the gda-dev2 tree,
> copy the gda code over, and just see what would be required to modify
> everything.  That would give me a feel for the amount of effort required
> to switch.

Do you want to do this in the gda-dev or would you like a new branch
to work from?   Branches are cheap.

> The code is almost at a stage that for many parts of it, I could
> abstract db access libraries.  No, I probably don't want to go down that
> path.

Hahah...  Umm, maybe, maybe not.  Sometimes abstraction is good.

> Phil

-derek

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