[Top] [All Lists]

vacation stuff

2005-07-01 10:25:02


One thing that's bugged me about the vacation extension is that it's not
entirely self-contained, in that the database has to be attended to via
some external means.  For any given vacation handle there are at least
the following data duties:

Instantiation.  This is easy enough: the very first time the vacation
statement is executed, the implementation can simply create the

Deletion.  Script author removes the vacation statement (or disables
it).  Deletion of data has to be done separately.  An environment can
certainly provide for this in some site-specific way.  OTOH the data
doesn't have to be deleted; in practice it does no harm, and users of
other vacation mechanisms probably don't always delete their vacation
database either (until the next initialization wipes it).  OTOOH,
a script writer who always uses different handles would cause old
data to pile up.  Might be worth some words of warning.

Reinstantiaton: Script author re-activates a vacation statement with the
same handle as before.  Stale data can be a problem here if the re-use
happens soon after the previous use.

One possible solution would be to introduce yet another argument or
option to the vacation statement, one that gives an instance key.  The
key could be any string, but there could be recommendations of common
choices, e.g. a date string 'yyyymmdd' of when the vacation is over
would be a convenient unique value.  This instance key would be stored
in the database that's associated with the vacation handle's data;
whenever a vacation statement is executed, if the stored key doesn't
match the specified key, the data would be re-initialized.

Alternatively, one could make it explicitly an ":end" value, so that
vacation action stops working on that date even if the author doesn't
update the script right away.

A downside would be that if the script has related vacation statements
in multiple places (which is sort of the point of :handle), the author
would have to be careful to keep the instance keys the same.  But that's
only a slightly greater burden than keeping the handles the same.



<Prev in Thread] Current Thread [Next in Thread>