[ZODB-Dev] Savepoints are invalidated once they are used

[Tim Peters]

[Dieter]
>>> If we do, we can (usually) create a one with the state after the
>>> "restore".

[Tim]
>> Sorry, I couldn't follow that sentence.

[Dieter]
> After I have restored to a savepoint "s", then the current state is the
> one saved in "s", thus the sequence:
>
>     s.restore() # and eliminate from stack
>     s = transaction.savepoint()
>
> essentially recreates "s" and the situation I would get would "restore"
> not eliminate "s" from the stack -- modulo the fact, that "s" now
> contains a new savepoint object (and other bindings to the old object no
> longer work as expected). An "s.push()" would eliminate this drawback (at
> the expense of an additional method).

Got it -- thanks.  Part of the hangup was simply that what you call
"restore" there is actually spelled "rollback", and for some reason I didn't
grasp that you were talking about the same thing (unsure why -- seems
obvious enough today!).

Anyway, for reasons explained before, making a savepoint would still need to
copy the index, so I don't see that this would save anything worth saving.
It might allow skipping an index copy when a _rollback_ is done (at the cost
of clumsier coding for the user), but I don't care much about that expense.

I do care about the expense of copying the index when a savepoint is made,
but all schemes so far have that expense, regardless of whether they allow
multiple rollbacks to a given savepoint (Jeremy misremembered when he wrote
that "the old" scheme made a copy (solely) to support multiple rollbacks;
it's also needed just to support nesting, which is the primary feature of
savepoints).