GDA: current status
plongstaff at rogers.com
Sat Dec 9 16:58:08 EST 2006
On Sat, 2006-09-12 at 13:19 -0500, Derek Atkins wrote:
> Quoting Phil Longstaff <plongstaff at rogers.com>:
> > - 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.
> > - 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
> 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
> > - 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
> > - 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)
> > - 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.
More information about the gnucash-devel