[Tim] >> ... >> But those details are all artifacts of exactly how your test case is >> written. As a general rule, if you do a rollback _beyond_ the creation >> of a new persistent object P, you shouldn't expect P to be in a useful >> state anymore ...
[Dieter Maurer] > As usual, an excellent explanation... Thanks <blush>! > However, it implies that "savepoint" and "rollback" do not work as a > naive user might expect. I, myself, would have been surprised that > "rollback" can do a third thing ("empty it") to an object other than > restore its state or leave it untouched. Well, two things here. First, I doubt it's new behavior. That is, I expect a similar test could be concocted out of subtransaction commits and aborts, in ZODB 3.2 or even 3.1. A difference may be that savepoints are actually useful <wink>, so people are more likely to bump into it now. Second, it was such a strain to write that explanation to begin with that I'm inclined to believe the behavior is wrong. For example, it might make better sense all around if, upon a rollback, objects created after the associated savepoint just lost the jar and oid (if any) they were assigned, leaving the rest of their state alone. > ... > Also, you might have mentioned the "add" method to explicitely inform the > connection about new objects that should be managed by the connection. Since that didn't appear relevant to the OP's reported problems, I didn't want to complicate the already-long explanation. That is, he could have introduced .add() calls until he was blue in the face, and I don't think that would have helped him. _______________________________________________ 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