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.

Godefroid Chapelle (aka __gotcha) http://bubblenet.be
For more information about ZODB, see http://zodb.org/

ZODB-Dev mailing list  -  ZODB-Dev@zope.org

Reply via email to