GDA: Status

[Nathan Buchanan]

Hi,
On Tue, Jun 3, 2008 at 8:19 AM, Derek Atkins <warlord at mit.edu> wrote:

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


We'd be in the same predicament as we would be in with GDA v3 - needing to
distribute our own code to make things work. I'm not saying this is ideal,
just that it isn't any worse.

>
> It means that *we* cannot release GnuCash 2.4 because a major
> dependency (GDA) isn't available in the major distributions.


This assumes we don't distribute any of it with our code. I believe we have
done this sort of thing in the past, but it was before my time here.

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


A very valid point.

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


This would be a significant shift in direction and it really would be up to
Phill to make this change (as he's doing the work!). Honestly I'd have no
objection to this, but the decision needs to come (IMHO) from the person
doing the work.

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


Point taken, absolutes are hard to defend ;)


Nathan

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



-- 
<><><><><><><><><><><><><><><>
"Even if you are on the right track, you'll get run over if you just sit
there" - Will Rogers