GDA: current status
plongstaff at rogers.com
Sat Dec 9 17:38:22 EST 2006
On Sat, 2006-09-12 at 17:14 -0500, Derek Atkins wrote:
> Quoting Phil Longstaff <plongstaff at rogers.com>:
> > 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 thing about FreqSpec is that they don't look like they need to be
evenly spaced. I don't know why you would not do that, but you might
want a FreqSpec to be "last friday of every month" or "15th and 30th of
every month" which Recurrence wouldn't handle.
> >> > - 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)....
I guess I'm looking at a phased approach. Multi-user operation is not
my itch and I am not really set up to test multi-user. I haven't put in
transaction use, though I guess that is needed even in a single-user
case to help ensure db consistency. I'd use a lock to just replicate
the current use of a lock file so that if two people are using the same
gnucash db, the second user would be warned of the first user's
presence. Ultimately, it wouldn't be needed.
> >> > - 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..
I agree. I said "for now". If anyone else wants to resurrect the old
File Select dialog or fix the File Chooser, please be my guest.
More information about the gnucash-devel