GDA: current status

[Derek Atkins]

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

-- 
       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