GDA: current status

[Phil Longstaff]

On Sun, 2006-10-12 at 12:50 -0500, Chris Shoemaker wrote:
> > While Recurrence has seperate API for computing the next
> > instance of a single Recurrence vs. a List<Recurrence>, the FreqSpec
> > just treats them both with the same interface.  
> 
> Good point.  I'm open to adapting this, if necessary.
> 
> > 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.

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.

Phil