[ZODB-Dev] BTree corrupted after conflict resolution

[Tim Peters]

[Dieter Maurer]
>> Almost surely, we must add a further restriction for BTrees:
>> the keys must not be persistent objects.

[John Belmonte]
> I think that would be an unreasonable restriction.

It sure appears that this restriction has always been there in reality, and
that you're the first to *try* using a persistent object as a BTree key and
notice that doing so doesn't work sanely with conflict resolution.

> If the server context can access the _p_conflictResolution method
> of a class, why not __cmp__, etc.?

The _p_conflictResolution method of a BTree bucket is what's getting called
here, and that has nothing to with getting at the __cmp__ method of classes
of contained objects.  Even it if it got at the latter, having an unbound
__cmp__ method for your key class doesn't do any good without also
materializing the instances of your class getting compared.  The states
passed to _p_conflictResolution() now don't materialize persistent
subobjects -- they're "represented" by instances of the internal
PersistentReference class instead.

If conflict resolution were changed to materialize persistent subobjects
first, then it might work as you hoped.  But that's a big change, and I
doubt it can happen -- it's not just that persistent subobjects would have
to be materialized, but also because they come from three potentially
distinct states, potentially three distinct revesions of each persistent
subobject would have to be materialized.  God only knows what all would
break then.  Patches discouraged <wink>.