GDA: current status

Derek Atkins warlord at MIT.EDU
Sun Dec 10 14:52:08 EST 2006


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.

> 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.

> Phil

-derek

-- 
       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



More information about the gnucash-devel mailing list