On Apr 27, 2007, at 3:24 PM, Terry Hancock wrote:

> David Binger wrote:
>> I think you are talking about the ZODB feature called versioning,
>> which I understand to be deprecated and faulty (but nevertheless
>> cool to see working in a Zope application).
>
> I don't think so. I just want a simple 'undo'/'redo'.

Are you saying that there is an undo feature in ZODB that is not
called "versioning" in ZODB, or that I am mistaken about the
deprecation of versioning.   I can't tell what you mean here.

>>> If it can't do it, how hard would it be to add, do you think? Is it
>>> something I could bolt on by sub-classing connection? Does the
>>> storage
>>> model support the kind of rollback I'm talking about?
>>
>> That would be a difficult path to take, but not impossible.
>> Durus does not maintain transaction timestamps or version
>> numbers, so one challenge would be to determine which
>> transaction you really want.
>
> Not a problem. The user would pick "save points", and the game would
> just save the current transaction number. All I need is the ability to
> recover the state at that transaction number (it's okay if I have to
> throw away later changes).

Maybe you could just save the length of the file at that time.
A rollback would just require truncating the file to that point
and starting with a new connection.  (No packing allowed, though).
The old "Storage" would be unusable because the offset index
would no longer work correctly.

>
> So, if I know exactly which transaction I want, is it relatively easy
> from there? Can I just throw away all the later changes and recover
> the
> state at that transaction? (And, of course, how?)

If you can afford to make a new Connection with a truncated file,
that would
be easiest.