[ZODB-Dev] BTree corrupted after conflict resolution

[Christian Robottom Reis]

[Jeremy]
> Perhaps we should define an __cmp__() method that raises an error on the
> stub objects that conflict resolution provides.
>
> [me]
>> Well, wouldn't that just be a roundabout way of making it explicit
>> that nothing but simple types can be used as BTree keys (since no
>> custom __cmp__ can be provided), or are you considering the
>> zero-concurrency situation? :-)

For the record, I was driving towards a suggestion that if it's a
problem with evil edge-cases that are bound to bite late in the life of
an application, OxBTrees should just forbid adding Persistent instances
as keys (instead of raising errors because of __cmp__ being called
during conflict resolution). This would however (and perhaps unfairly)
hurt people that wanted to use Persistent instances as keys in a
completely non-concurrent application, which is why I added the "or"
part of my phrase. 

But what zero-concurrency application stays that way for long?

> [Dieter Maurer]
> >> No. There is not problem to use class instances as keys,
> >> provided they provide a persistent (complete) ordering
> >> and they are not persistent.
> 
> [Christian]
> > Okay. But then how do they provide complete ordering if not via
> > __cmp__ or __rcmp__, given that they are instances?
>
> [Tim]
> By supplying __cmp__.  Your original "since no custom __cmp__ can be
> provided" didn't make sense.  You can always slap a custom __cmp__ on a
> class.  It apparently doesn't do any *good* to supply a custom __cmp__ on a
> *persistent* class so far as conflict resolution is concerned, but Dieter is

Sorry about that. 

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.

Is it because PyObject_Compare only invokes __cmp__ when the instance
has state (IOW, isn't a ghost)?

Take care,
--
Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 261 2331