[ZODB-Dev] [zopefoundation/ZODB] 49919d: test for POSKeyError during transaction commit

[Godefroid Chapelle]

Le 05/02/14 15:44, Jim Fulton a écrit :

>> >When setting a key value pair on a new (not already committed) instance of a
>> >standard BTree, readCurrent method is not called on the connection.
> This is with your change, right?

No, it is without my change.

>> >My understanding is that it is due to the fact that _p_jar and _p_oid are
>> >only set during transaction commit.
> They can be set earlier by calling the connection add method.
>
> This is used often for frameworks that use object ids at the application level.

I do not understand what you mean.

>> >
>> >However, with a new BTree instance that also inherits from
>> >Acquisition.Implicit, readCurrent method is called on ZODB connection when
>> >setting key value pair. The only explanation I found is that this instance
>> >_p_jar attribute has a value (acquired in a way or another ?).
> You could also simulate this by adding an object to a connection using
> a connection's add method.
>
> Wanna update the test to use this technique instead?

I'll make a try. But I think I remember having already tried (I have 
been working on this a few times since september).

So if I do not succeed in a reasonable amount of time, I'll come back here.

>> >In this case, when readCurrent is called on an object created during a
>> >savepoint and this savepoint is rolled back, the oid is leftover in the
>> >Connection._readCurrent mapping. This leads to the POSKeyError when
>> >committing later as checkCurrentSerialInTransaction cannot check the object
>> >since it went away at rollback.
>> >
>> >This brings us to the fix I propose: calls to readCurrent should not track
>> >objects with oid equal to z64.
> ...
>
>> >This was a very long explanation which I hope will help to confirm the fix
>> >or to come up with a better one.
>> >
>> >PS: keep in mind that english is not my mothertongue.
> :)  You do very well.
>
> I think your fix is correct.  As you point out, It doesn't make sense to
> guard against conflicts on new objects.
>
> I think a cleaner test could be written using the connection add method.
>
> Jim
-- 
Godefroid Chapelle (aka __gotcha) http://bubblenet.be