On Sat, 2006-09-12 at 13:19 -0500, Derek Atkins wrote: > Quoting Phil Longstaff <[EMAIL PROTECTED]>: > > > - 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 _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
