[ZODB-Dev] strange savepoint behavior

[Tim Peters]

[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.