>>> If we do, we can (usually) create a one with the state after the
>> Sorry, I couldn't follow that sentence.
> 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
For more information about ZODB, see the ZODB Wiki:
ZODB-Dev mailing list - ZODB-Dev@zope.org