GDA: current status

[Chris Shoemaker]

On Sat, Dec 09, 2006 at 06:37:55PM -0500, Derek Atkins wrote:
> 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.

Looks may be misleading.  Just because Recurrence has 3 members
instead of FreqSpec's 17 doesn't mean FreqSpec can represent more.  In
fact, Recurrence is more general, both in the types of repetition it
can specify, and in that it also represents the starting date.

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

Recurrences don't have guids, and have no relation to QofInstance or
QofEntity.  They are not "engine objects".  They are "data".

> >>
> >> Well, I think Freqspec is Recurrence + last-executed + number of executions.

Actually, not at all.  Things like last-executed, number-executed,
start and end dates, and several more are all part of SX, not
FreqSpec.

It would be more accurate to say, conceptually, 

 Recurrence = FreqSpec + starting date.

> >> I dont really care how they get combined, but really there should be
> >> only one.

Phil, if you want to adapt FreqSpec + starting date from SX into
Recurrences, you're more than welcome, but 1) it's really outside the
scope of gda-dev, so I'd recommend another branch, and 2) be warned
that doing it right is a lot of work, (or it would already have been
done).

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

Actually, it's much simpler than that.  "Last Friday of every month,
beginning yester day" is represented as {12/8/2006,
PERIOD_LAST_WEEKDAY, 1} (mult=2 would mean "last friday of every
_other_ month, etc.)

BTW, one difference between FreqSpec and Recurrence: FreqSpec can
actually represent an internally-linked tree-structure of nested
"composite" FreqSpecs.  I have no idea why.  It's a very inefficent
data structure, since only the "leaves" carry the data, and the
structure is meaningless.  The Recurrence API handles this with a
GList of Recurrences.  However, I believe it's an unused interface at
the moment.

-chris