GDA: current status
plongstaff at rogers.com
Sun Dec 10 16:08:08 EST 2006
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
You're right. I see a lot of good stuff there.
More information about the gnucash-devel