Posit: Unlimited "Undo" in fP?

Fairlight fairlite at fairlite.com
Wed Jul 25 18:04:22 PDT 2007


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 variablise lookup file names (to my knowledge).  If you
could, I think it'd be possible if you could always guaranetee 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->
-- 
Fairlight->   ||| "Nice girls, not one with a defect | Fairlight Consulting
  __/\__      ||| / Cellophane shrink-wrapped, so    |
 <__<>__>     ||| correct" --Elvis Costello          | http://www.fairlite.com
    \/        |||                                    | info at fairlite.com


More information about the Filepro-list mailing list