>> 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 ...
> As usual, an excellent explanation...
> 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:
ZODB-Dev mailing list - ZODB-Dev@zope.org