[Tim Peters] ... >> I'm not sure I follow this: old code could not be using savepoints >> directly, so what would break in code that stuck solely to subtxn >> commits? > ... >> So I don't see how backward compatibility would be injured. BTW, I >> tried it, and all the ZODB tests pass with this change.
[Jim Fulton] > When you so commit(1), the promise is that, if the top-level transaction > commits, then any work done up to the commit(1) is committed. Consider > this scenario: > > - new code: s = transaction.savepoint() > - old code: foo.x = 42 > - old code: transaction.commit(1) > - new code: s.rollback() > - old code: transaction.commit() > > Now, the old code expected that foo.x was 42. It did a commit(1). But, > in fact, if we can roll back s, then in fact, the old code can't count on > the semantics of the commit(1). This would be a change in behavior for > subtransactions. Right, _mixing_ the two can create surprises, and on both sides (for the new code too: since savepoints _do_ nest, I think it's at least as surprising for the author of the new code that calling old savepoint-free code could invalidate their savepoint). > Subtransactions only provide one level of nesting. They are not the same > as savepoints. More, savepoints are better (IMO). > Now, I don't know for sure that anyone depends on the non-nestedness of > subtransactions. Mostly, subtransactions are used to checkpoint > incomplete changes to disk. So perhaps the backward compatibility risk is > small. It would surely be a much happier outcome all around if ZODB users "simply" stopped using subtxns now. To set a good example, I think I'll take a bit of time today to rewrite the parts of ZODB that still use them (there is a little! at least one tool script and ExportImport.py). _______________________________________________ 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