[ZODB-Dev] Re: BTree corrupted after conflict resolution

[Casey Duncan]

On Thu, 04 Mar 2004 13:08:42 -0500
John Belmonte <john at neggie.net> wrote:

> Casey Duncan wrote:
> > At the very least it should be a great big blinking "Enter at your
> > own risk" sign above the door.
> > 
> > As a personal rule I never use anything but simple types in BTree
> > keys, because I know I stand little to no chance of getting it right
> > otherwise. I've used BTrees a lot and frankly I've never had
> > anything but a superficial reason to use persistent objects as BTree
> > keys.
> 
> Note that this issue applies to BTree sets as well.  Is it
> unreasonable to want a set of first-class persistent objects?

It's not unreasonable, it's just not easy (and perhaps not possible if
the conflict resolution is broken as was surmised). Traditionally Zope
has skirted this problem by assigning objects integer ids and making
sets and trees of those instead.

I am using a similar strategy for pypes which has an identity service
whos primary function is to assign simple ids for objects. Then there
are set and graph types you can use which contain trees and sets of ids
that transparently handles id<->object resolution using the service.

I do know of Zope applications that have successfully used 1st class
persistent objects as BTree keys. There was great pain to get them to
work, but in the end I think they did and still used persistent object
keys. I know one of the problems they ran into was conflict resolution
code running on the storage server. I believe they had to put the key
classes on the server to solve one of those types of problems. I wasn't
part of the project though so I can't be more specific.

-Casey