Remove Bill/Vendor

Linas Vepstas linas at linas.org
Wed Mar 26 10:10:38 CST 2003


On Wed, Mar 26, 2003 at 10:51:10AM -0500, Derek Atkins was heard to remark:
> True, and most of the code does this (including the business
> features).  However I think Bill was requesting an ability to
> undo _AFTER_ commit.  And _that_ isn't really possible.

I'm not saying you should do it, but ...
In principle, if you save a copy of the old data after every commit,
then you could undo (as long as you were careful to do each undo
in reverse chronological order).   

(One of the points being that the chunk of code that does the 
commit is also the natural, 'centralized place'  where a hook
could be added to record the old info, the info needed for the 
undo.)

The other point being (and maybe this is a bit bombastic,
but this is why I didn't drop the issue), 
is that when the begin/commit is designed right, this makes 
many other things possible.  Undo is one.  The audit trail 
is another.  The multi-user delete issue in the other email
is actually kind of like an undo issue.  And, in principle,
if the audit trail is implemented correctly, then you can 
implement 'undo' by walking through the audit trail, and
unapplying the transactions in reverse order.  Done correctly,
you could rewind them all the way to the very begining,
and finish with a clean slate.   (that would be the automated
test case, wouldn't it?)


--linas



> -derek
> 
> linas at linas.org (Linas Vepstas) writes:
> 
> > On Tue, Mar 25, 2003 at 04:01:13PM -0500, Derek Atkins was heard to remark:
> > > I'm not sure what you mean by "general purpose undo".  There is not
> > > a centralized place where all objects are added/removed..  So there
> > > is no way (short of rototilling a lot of code) to re-architect the
> > > system to allow this.
> > 
> > Derek,
> > 
> > Please excuse the following, cause I know yo know it already, but your remarks
> > scared me  ...
> > 
> > One of many reasons for having begin/end constructs around data is to
> > be able to mark up atomic, undo-able data chunks.  In principle,  If 
> > you surrounded your data correctly with being/end in the right places 
> > (this also requires your data design to be 'normal' or 'orthogonal'),
> > then undo is 'easy'.   You implement undo by using begin/end to make a 
> > copy of the old data.  At 'end', you string this copy onto your necklace 
> > of saved undo thingies.  Implementing undo is then a matter of pulling
> > pearls off the necklace.
> > 
> > Easier said-than-done.  One important issue is that the data really be 
> > normal, so that you only need to save a copy of the atomic data chunk, 
> > instead of saving the entire state of the whole damn system.   Clearly,
> > if saving the state of the whole system was needed for undo, then indeed 
> > undo would be untenable.
> > 
> > --linas
> > 
> > 
> > -- 
> > pub  1024D/01045933 2001-02-01 Linas Vepstas (Labas!) <linas at linas.org>
> > PGP Key fingerprint = 8305 2521 6000 0B5E 8984  3F54 64A9 9A82 0104 5933
> 
> -- 
>        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

-- 
pub  1024D/01045933 2001-02-01 Linas Vepstas (Labas!) <linas at linas.org>
PGP Key fingerprint = 8305 2521 6000 0B5E 8984  3F54 64A9 9A82 0104 5933


More information about the gnucash-user mailing list