GDA: current status

[Phil Longstaff]

On Sun, 2006-10-12 at 14:52 -0500, Derek Atkins wrote:
> Quoting Phil Longstaff <plongstaff at rogers.com>:
> 
> >> > As you mention, composite FreqSpecs can be arranged in a tree, as
> >> > well, which is nice, though unused in GnuCash.
> >>
> >> I really have no idea why it's "nice", since it doesn't apparently
> >> mean anything.  OTOH, if there was a plan to implement "AND" nodes,
> >> where occurrances happened only when all children had a concurrent
> >> occurrance, I could see why a tree structure would be useful.
> >> Personally, I think that's overkill, though.
> >
> > This has been an interesting discussion about the merits of Recurrences
> > vs FreqSpecs.  Unless someone can do the work to convert GC to use only
> > 1 of them, I will implement both in the backend.  I have the same
> > feeling about GDates and Timespecs.  I have implemented both even though
> > there is a redundancy there.
> 
> I'm okay with this ONLY if we understand that this is TEMPORARY.  In
> NO WAY should this continue into a release.  I consider it imperative
> that we merge into a single data structure before the SQL backend is
> merged into trunk.  But as a temporary measure, to get the rest of the
> code working and to test all the issues, doing both is fine.  Just keep
> in mind that it IS only temporary.

I am implementing the backend for GC as it now exists.  If someone else
will provide a branch with changes to object structures, and you want
that branch merged with the GDA branch, I will merge it.  I'm not going
out of my way to clean up the GC structure because I just don't have the
time, even though I'd love to see it done.

> 
> > Another note about GDA status.  If you enter a transaction and press
> > Enter to commit it while in a split, it seems OK.  If you are back on
> > the Transaction line, I come across a segv.  It seems to be related to
> > the fact that I am using the standard transaction and split setters and
> > xaccTransCommitEdit().  This last function has nasty side effects for me
> > because it triggers all sorts of extra queries which eventually lead to
> > the split list being corrupted.  I'm back to thinking about a
> > serialize/deserialize type interface between the engine objects and the
> > backend.  The file backend would either not implement them or would do
> > nothing (similar to not implementing the begin/edit commit functions).
> > This way, a new transaction can have its values loaded without
> > triggering all of the other side effects.
> 
> Are you following the same process as src/backend/postgres/PostgresBackend.c
> pgendDisable() and pgendEnable()?  If not, you should.  It should fix
> lots of these issues for you.
> 
> You should use the PG Backend as a prototype/example and follow their
> example.

You're right.  I see a lot of good stuff there.

Phil