Posit: Unlimited "Undo" in fP?

[Bruce Easton]

Richard Kreiss wrote Thursday, July 26, 2007 12:28 PM:
>
> Mark Luljack wrote Wednesday, July 25, 2007 9:04 PM:
> >
> > Well, I was thinking about this from my article when I wrote
> > it late last week.  I had a section on software having Undo features.
> >
> > Got me thinking about fP...
> >
> > What happens if you take a table on which you're altering
> > data, and @wef* or any other appropriate events, you actually
> > take a "snapshot" of the record into a secondary backup
> > table, complete with an added session and sequence number?
> >
> > In this fashion, you could assign some way of triggering an
> > Undo, which would take data from the last sequence number on
> > the stack for that session.  After the session (however you
> > define it...say you have a step that finalises a
> > transaction), you could just delete all "step" records in the
> > backup file for that session number.
> >
> > Technically, you could implement Redo as well by keeping a
> > counter of which step you're on and just pulling the sequence
> > number forward instead of backwards, and not deleting -any-
> > records until things are finalised.
> >
> > I thought this might be an interesting thing to toss around
> > as an idea for implementation.  Could be handy in some
> > environments/instances.
> >
> > Technically, it could be expanded to header/detail as well,
> > obviously at the cost of some (more!) processing.
> >
> > Actually, I was thinking it might be painful to have to code
> > new Undo/Redo for each table, but it might be possible to
> > make is modular, as long as you had 997 fields or less in
> > actual use so you have two available.  It's possible to do
> > with special formatting and use only 1 field, I suppose.
> > But basically just make a copy of any file you want to have
> > Undo/Redo, and the only thing that needs to change is the
> > lookup name.  The rest of the code could be handled
> > generically with an array laid over the lookup alias, so you
> > just store fields 1-997, period, file agnostically.  Minimal
> > processing rewrite.  I can't think of a way to make it a
> > "true" module since you can't variables lookup file names
> > (to my knowledge).  If you could, I think it'd be possible if
> > you could always guarantee the same index for the one field.
> >  And I -know- you can't use a variable for the index--I've asked.
> >
> > Anyone have opinions on this idea or an expansion thereof?
> > It's really just something that occurred to me suddenly and
> > has been an intellectual exercise since then.  If it's useful
> > to someone in some form, cool.
> >
> > mark->
>
[..]
>
> Now this is not a roll back but if one is going to implement
> something like
> this, using a qualified file would be easiest.
>
[..]
Yeah, a roll back of the entire record - so if you had session# and
seq# as part of the map (where they would only be used on the historic
qualfied key), then you could show a browse of the last x versions
of the record by showing the qualifier records that match the session#
in seq order.  Heck, I guess the browse could have hot-key options to
allowing viewing all the fields that the operator might need to see,
and when a (historic) record in the browse was selected, one could
prompt the operator for a specific list of field(s) to restore back
from the selected record's value(s) to the current record.

> The other option, which I have done for another client, is to
> track changes
> to specific fields in a file.  All changes are logged to the same log file
> showing the field name and field #, the starting value and the new value,
> the file name, process, user name and computer name and the time of the
> change.

Richard - does this happen when the record is saved or each time the
operator leaves the field?

For the ability to bring back values from the current session prior to
saving a record (where the operator has changed a field one or more times),
I might still be tempted to build a separate file on:

1.session#
2.field#

and then let the stack of previous values be stored in fields 3+ of that
same record (handled then by an array) (where @wlf triggers pushing to the
stack).

OR, maybe the file could have the form:

1.session#
2. field#
3. seq#
4. value at this seq#

and that would be it - in this case, instead of an array being built
against fields 3+ to be the stack, the stack would be represented
by getnexting thru, pushing and popping against the series of records
session#, field#, seq#.

[..]

Bruce


Bruce Easton
STN, Inc.