GDA: current status
warlord at MIT.EDU
Sat Dec 9 18:37:55 EST 2006
Quoting Phil Longstaff <plongstaff at rogers.com>:
>> >> > - 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 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
warlord at MIT.EDU PGP key available
More information about the gnucash-devel