GDA: current status

[Phil Longstaff]

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

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

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

Phil