[ZODB-Dev] BTree corrupted after conflict resolution

[Dieter Maurer]

Christian Robottom Reis wrote at 2004-3-6 13:08 -0300:
> ...
>It's still not clear to me how this works, however: let's say a BTree
>holding non-persistent instances conflicts; it will invoke its conflict
>resolution handler and attempt to sort out how to solve the conflict by
>looking at its keys and comparing them to see which order they should be
>placed in (I see in bucket_merge it's more involved than this, but hope
>it's a reasonable high-abstraction description).
>
>What I fail to see is why __cmp__ will be invoked (to determine key
>order) for a non-Persistent instance, but not for a Persistent instance.

To keep things simple, the ZODB developpers decided to
handle conflict resolution at the "one persistent object at
a time" level.

Usually, when a persistent object references
a persistent subobject, this subobject is dynamically
(and transparently) loaded (if necessary). However,
"access to subobjects" would break the "one persistent object
at a time" policy (and bring quite a few technical difficulties).
Therefore, persistent subobjects are represented by
a proxy (a "PersistentReference") that does not load
the subobject but is passive.

Conflict resolution uses the "__cmp__" method for
both non-persistent as well as persistent instances.
However, for non-persistent instances, it is the "__cmp__"
of the correct class and for the correct objects.
For persistent instances, it is the "__cmp__" of the proxy
and not of the true class/instance.

-- 
Dieter