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