GDA: Status

[Nathan Buchanan]

On Mon, May 26, 2008 at 5:04 PM, Derek Atkins <warlord at mit.edu> wrote:

> Can't you just use "CREATE IF NOT EXIST" ?  Or is that not portable enough
> across various SQL implementations?


This is definately not portable. IIRC, it's a MySQL extension.

>
>
> Part of me is really thinking that GDA is more trouble than it's worth.
> I'm sure Esodan will vociferously argue against this, but perhaps we
> should drop GDA and choose something that actually works?
>
> -derek
>
> Quoting Phil Longstaff <plongstaff at rogers.com>:
>
> > Graham Leggett wrote:
> >> Phil Longstaff wrote:
> >>
> >>> Well, V4 basically works with the sqlite provider.  There were a number
> >>> of memory leaks and other small issues.  However, there are a number of
> >>> problems with the V4 mysql provider - it's not ready for use.
> >>>
> >>> I've decided to switch back to V3 for now.  I'll continue to supply
> >>> patches and if I have to, I'll pull it into the tree under 'lib'.
> >>
> >> Considering that V3 is not being actively developed, and that bugfixes
> >> to v3 won't be accepted, is it not safer to develop for V4, and get the
> >> upstream project to fix any problems involved? How far away is the V4
> >> mysql provider?
> >
> >
> > I don't know how far away the V4 provider is.  They have a
> > meta-information system which allows you to access info about the db
> > structure (e.g. which tables exist) and the meta-information system has
> > been redesigned for V4.  It hasn't been implemented for mysql yet, so
> > when gc starts, it tries to create all of the tables, even if they
> > already exist.  Note that it was a meta-information bug which was
> > causing a problem in the gc-V3 code which was not accepted.  The bug is
> > that if you delete all db tables and then ask libgda to update the
> > meta-information, it still thinks that the 2nd table exists (usually,
> > billterms) so that it won't be created.  This could happen when you are
> > trying to save-as to a db, so billterms won't be saved, and lots of
> > business objects will be screwed up.
> >
> > I see 3 possibilities:
> > 1) Do libgda V3 maintenance ourselves by sending in patches and asking
> > for them to be applied.  For the particular bug I found, I didn't send
> > in a patch, but asked for the bug to be fixed.  Maybe they won't fix
> > bugs but will apply patches.  They would probably not create new
> > tarballs, so anyone who wanted to use gc-libgda would need to check out
> > the V3 trunk from svn and build from source.
> > 2) Pull the libgda-V3 branch into the gc tree under lib.  The GC team
> > would maintain it.  This has the advantage that it would not be an
> > external dependency any longer, so anyone who wanted to try the gda
> > backend could.  The obvious disadvantage is a mess of code that nobody
> > knows but that we need to maintain.  Once libgda-V4 is further along, I
> > can switch back to V4.
> > 3) Change my decision and switch back to V4.  I have basic operation
> > with sqlite working.  There is at least 1 regression (I can't create the
> > index on the slots table) which would have performance implications.  I
> > don't know where the problem with index creation is.  However, there are
> > some improvements.  The libgda-V4 statement structures can represent SQL
> > operations which were not possible in V3, and which would improve
> > performance.  However, as I said above, the mysql provider is missing
> > some major functionality.  I don't know about postgresql.
> >
> > There are other issues with the whole gda backend which I need to work
> > on and which are independent of which version of libgda is used:
> > 1) some of the dialogs (e.g. price editor) create an object when the
> > dialog is opened and then modify it as the dialog is used.  This can
> > cause commit requests for objects which break db constraints (a price
> > must have a commodity, but a save request may come before the commodity
> > is set).  Fixing this requires a change to db logic to only create the
> > object when 'OK' is pressed.
> > 2) versions for tables and handling of version updates
> >
> > I had decided to stay with V3 because it would not be a step backwards
> > in functionality.  I wanted to try V4 to see what shape it was in, to
> > get some experience with it, and to provide some feedback to the
> > developers before they release.
> >
> > I think I'll stay with V3 for now and monitor V4.  When they implement
> > the V4 mysql meta-info code, I'll reconsider switching.  I'll also do a
> > bit of testing to see how postgresql looks.
> >
> > Phil
> >
> > _______________________________________________
> > gnucash-devel mailing list
> > gnucash-devel at gnucash.org
> > https://lists.gnucash.org/mailman/listinfo/gnucash-devel
> >
>
>
>
> --
>       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
>
> _______________________________________________
> gnucash-devel mailing list
> gnucash-devel at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>



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