Quoting Phil Longstaff <[EMAIL PROTECTED]>: >> >> > - 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.
Sure it could. Recurrence has: PERIOD_END_OF_MONTH, /* This is actually a period plus a phase. */ PERIOD_NTH_WEEKDAY, /* Also a phase, e.g. Second Tueday. */ PERIOD_LAST_WEEKDAY, /* Also a phase. */ I'm not exactly sure how you'd handle "last friday", except perhaps by "nth weekday" where n is -1 and the weekday of the first is friday. >> 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. Well, you can test multi-user by running two instances of gnucash against the same database at the same time. :) -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH [EMAIL PROTECTED] PGP key available _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel