GDA: Status

[Phil Longstaff]

Derek Atkins wrote:
>> 2. Use GDA V4. We will probably send time fixing bugs here, but we are almost
>> guaranteed that a release will happen. The advantages of this approach is that
>> we will be current with the new GDA and releases will be done for us (or in
>> conjunction with us - depending on how closely we work with the GDA team).
>> Work done here will not be towards a dieing version. The disadvantages are
>> that we will probably be limited to sqlite until the other providers are
>> completed. We may have to distribute pre-release versions of the code until
>> there is a 4.0 release, but after that, we hand it over to the "official"
>> releases.
> 
> The assumption here (in both #1 and #2) is that GDA-4 will be
> released sooner than that gda-dev branch will finish.  I have seen
> no such assurance.  What happens if gda-branch finishes, gets
> merged back into trunk, but GDA-4 hasn't been released yet?
> It means that *we* cannot release GnuCash 2.4 because a major
> dependency (GDA) isn't available in the major distributions.
> 
> Also, in the past 18-24 months we've seen GDA move from 1.3
> to 2.99 to 3.0 to 3.9/4!  Are we really confident that in another
> 9-12 months they wont scrap this and move to GDA-5 and leave us
> in the dust yet again?

According to the libgda development mailing list, they are targetting
2.26 which seems to be scheduled for Q1 2009.  Depending on distro
release schedules, this means it may not be out in the wild until Q3
2009.  I expect the gda-dev branch to be finished long before then.

> 
>> 3. Use Libdbi/another approach. Advantages: we hope they are more stable and
>> bug free, but do not know. Disadvantages: we have to re-do all the work done
>> to integrate GDA :(.
> 
> We don't need to hope.  Libdbi *IS* more stable and bug free.  DBI has
> been out in the wild for AT LEAST half a decade, maybe more.  It has
> providers for all the major OSS DBs as well as ODBC to connect to the
> non-OSS DBs.  It is still being actively maintained but it's so rock
> solid that there just isn't much that NEEDS to be done.
> 
> Another advantage is that DBI has been out in the wild and use-tested
> for a long time, so it's unlikely that we'd find any major gotchas
> along the way.  It's benefits (and drawbacks) are well understood
> by the user community.
> 
> The one major downside of DBI is that it IS lower-level than GDA.  It
> does not really abstract out the query language like GDA does.  It
> does provide a bunch of "type" abstractions, but doesn't provide a
> query abstraction.
> 
> I also disagree with your statement of disadvantages.  We would not
> have to re-do ALL the work done to integrade GDA.  However we WOULD
> have do re-do a lot of it.

>From what I know now, we wouldn't need to redo *ALL* the work.  However,
it might be roughly equivalent to the amount of work to move from GDA-3
to GDA-4, which was a few weekends.  A lot of the changes are simply
based on the requirements of any SQL backend.

>> My personal opinion is that we go with #2, use GDA V4. We will need to do
>> fixes in either #1 or #2. From a maintenance point of view it's better to put
>> those fixes towards a version that has a reasonable chance of a release. (This
>> does, of course, assume that V4 actually gets completed). At best the other
>> providers get implemented and we have all of them available. At worst, we're
>> stuck with sqlite for a while.
>>
>> If we really need mysql/postgres right away - it's going to involve
>> significant work regardless of the option chosen.
> 
> I'll restate my opinion here again.  I think our #1 target is SQLite.
> We need to move our home users off of XML and into a DB so we can get
> the benefits of save-on-commit.  Then MySQL and PG are tied (in my
> mind) for #2.
> 
>> Phil, do you have a preference? It's probably your preference that counts ;)
> 
> I'm not going to push for DBI over GDA, however I do want to make sure
> we're making an educated choice here and not just choosing GDA because
> it's shiny and new and happens to have a 'G' in the name.  I also
> want to make sure we're chosing a technology that WILL be there for
> a long time and wont get us stuck in a situation where we're spending
> all our time "keeping up" with them changing APIs out from under
> us.

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.

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.
2) potentially, an abstraction internal for each db driver just to
handle any differences for each db.
3) a new url format.  For sqlite, not a problem, but would be needed for
mysql/postgres.
4) switch gda calls to dbi calls
5) lots more.

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.

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.

Phil