[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). _______________________________________________ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@zope.org http://mail.zope.org/mailman/listinfo/zodb-dev
