GDA: Status

[Derek Atkins]

Hi,

Sorry for the delay, but I've been busy offline most of the
weekend and yesterday so I've let this thread sit for a bit.
More comments inline.

"Nathan Buchanan" <nbinont at gmail.com> writes:

> So...In the end, what's our options?
>
> 1. Use GDA V3. We will spend time fixing bugs in V3 that will probably not be
> released in a bugfix release of GDA. The advantages of this approach are that
> we get access to sqlite, mysql, and postgres. The disadvantage is that we will
> probably have to ship our own version of GDA, and in a few years, this will
> probably be out of date, requiring the switch to V4 anyway. We will expend
> significant energy to have it working "now", much of this energy will be lost
> when moving to V4.
>
> 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?

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

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

As an example, just look at what's happening in AqBanking.  It's not a
zero-effort task to move from AqB-2 to AqB-3.  Luckily that work is
limited only to a small section of Gnucash.  Now imagine if we finish
with GDA-4 and they move to GDA-5 (just like we almost finished with
GDA-3 and now they're moving to GDA-4).

Just let that simmer a bit.

-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