plongstaff at rogers.com
Mon May 26 19:32:23 EDT 2008
I'll leave the specific detail of "CREATE IF NOT EXIST" aside.
I think gda is a general solution that will allow us to meet the
requirement of supporting sqlite, mysql and postgresql. Gnucash is
currently at 2.2.5 moving towards 2.4. If I could work full time on it,
the gda backend might be fully integrated into gc in 3 months. Given I
only have evenings and weekends (if that), make it 6-9 months.
Re dropping GDA: rather than drop it, I think it would be better to pull
it into the tree. That would at least give us the assurance that
everyone who wants to use the gda backend has a consistent set of fixes
Derek Atkins wrote:
> Can't you just use "CREATE IF NOT EXIST" ? Or is that not portable enough
> across various SQL implementations?
> 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?
> 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.
>> gnucash-devel mailing list
>> gnucash-devel at gnucash.org
More information about the gnucash-devel