GDA: current status

Derek Atkins warlord at MIT.EDU
Sat Dec 9 17:14:43 EST 2006

Quoting Phil Longstaff <plongstaff at>:

> On Sat, 2006-09-12 at 13:19 -0500, Derek Atkins wrote:
>> Quoting Phil Longstaff <plongstaff at>:
>> > - To avoid having the backend commit everything twice (because of the
>> > Qof two phase commit protocol), saved objects are marked clean when
>> > committed.  To do this, I need to reach right into the QofInstance
>> > structure and clear the dirty flag.  There should be a better way to do
>> > this.  Note this also keeps the book from being marked dirty.  Q: If a
>> > db backend becomes the standard and xml is only for import/export, does
>> > the concept of clean/dirty disappear?
>> Yeah, with a DB backend the book should never be dirty.  So, yeah,
>> this is the right thing to do; you should clear the dirty bit when
>> you commit.  Perhaps there needs to be a qof_instance_clear_dirty().
> My question about "should the concept of clean/dirty disappear" is to
> raise it as an architectural change.  Should these be put into bugzilla?
> If so, I will.

Oh, no, architecturally this should stay, because it's still reasonable
to have the concept of full-save backends.  Besides, if this change
were to happen it's still a few major releases out, so no point in
thinking about it now.  We wouldn't remove the XML Backend for
at least two releases after SQLite support gets in, so you can't
NOT handle the dirty-bit.

>> > - Recurrences are currently only used by budgets, and recurrence
>> > save/restore is included in the budget save/restore code.  If
>> > recurrences will eventually be used elsewhere in GC, recurrence
>> > save/restore code may need to be split out on its own (separate
>> > recurrences table?)
>> *GRR*  I knew this was going to be a problem.  I really should have
>> been more insistant that Chris fix this BEFORE 1.8.   Recurrence and
>> Freqspec should merge into a single data object.  We don't need both,
>> and having both just duplicates code and confuses the data model.  They
>> perform essentially the same functions and even do it in fairly similar
>> ways.
>> It's unfortunate that they are still two separate objects.
>> For the DB backend I'd really like there to be only one (probably
>> Recurrence).  And yes, it should be its own table.
> I think Recurrence is a subset of FreqSpec i.e. FreqSpec can represent a
> lot more than a Recurrence can.  In any case, I will have 1 table and
> the back end will convert to that 1 table.  My choice (given my limited
> knowledge) is to use FreqSpec because it is a more general mechanism.
> If that generality is not desired, feel free to dictate otherwise.
> I just saw Chris's response that Recurrences don't need their own table.
> I'll let Derek and Chris hash out the larger architectural issues on
> this one.

Well, I think Freqspec is Recurrence + last-executed + number of executions.
I dont really care how they get combined, but really there should be
only one.

>> > - The backend has its own tables for objects which include db-related
>> > info.  Can these be merged with the engine object tables?
>> I dont understand the question.  Could you give a more specific example
>> of what you mean?
>> Keep in mind that the db backend certainly needs a table for its own
>> configuration, so you can keep track of, e.g., the currenct schema version.
>> This way we can easily update the database over time when we notice that
>> the DB is at schema version X and gnucash is at schema version Y and X < Y..
>> Or we could report an error if X > Y...
>> > Some engine tables don't exist (commodity), some have extra parameters,
>> > some don't have all needed parameters, some don't have setters for every
>> > parameter, some have an inappropriate setter, ...   I've often wondered
>> > if the engine object <-> backend interface should NOT use the standard
>> > get/set APIs but should be more of a serialize/deserialize interface
>> > where when an object is to be committed, the object's SaveYourself
>> > method is called.  This method grabs the backend and calls
>> > SaveThisParameter multiple times.  When loading, the object would be
>> > malloc'ed and then its RestoreYourself method would be called.  This
>> > would call the backend's RestoreThisParameter.  This would also solve
>> > the problem of commits occuring while an object is being loaded (I have
>> > a flag to catch these).
>> The way the PG backend did this was to clear out the backend pointer
>> during the load, so it didn't call back into the backend commit.  But
>> yeah, a Serialize(), Deserialize() "private" interface might be useful.
>> > - When a price is committed, the priceDB is also committed.  Could there
>> > eventually be multiple priceDBs?  The priceDB is currently ignored.
>> The PriceDB is just the collection of Prices.  I dont think we ever
>> have multiple PriceDBs.
> Is there any reason it is a first class object and not just a
> qof_collection?  I don't feel the urge to change it now, so I can log it
> in bugzilla.

Um..  I dont know why offhand; I'd have to look at the code and see what
the PriceDB actually has.   I dont think we ever have two PriceDBs in
a book, nor do I know why we'd ever want multiple PriceDBs in a book.

>> > - Multiple books?  The old postgres backend had a books table.  If the
>> > new db should have one, accounts (and other objects) should have a book
>> > guid field.
>> *ponders*  Might not be a bad idea to do this now.
> OK.  I'll add a books table (probably just a guid and a lock)

Not sure why you'd need a lock...  But I could imagine this as a way
to handle multiple periods..  Each transaction would belong to a specific
period (Book)....

>> > - If I try to "Save As" and type a url (e.g. gda://xxx), this gets
>> > converted to file:///home/phil/.../gda%3F%2A%2Axxx.  (I don't remember
>> > the % escapes exactly, but you get the picture).  I tried adding
>> > gtk_file_chooser_set_local_only( file_box, FALSE) but that didn't help.
>> I think it's a bug in the File Chooser..   We probably should revert back
>> to the GNC File Select dialog we used to have.  This bug has already
>> been reported against 2.0 because you cannot save as to postgres either.
>> This is.... unfortunate.  :(
> I'm going to leave this for now.

Well, we'll need some way to type in relatively-arbitrary URLs..

> Phil


       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL:    PP-ASEL-IA     N1NWH
       warlord at MIT.EDU                        PGP key available

More information about the gnucash-devel mailing list