[ZODB-Dev] Re: persisting "immutable" classes

[John Belmonte]

Casey Duncan wrote:
>>Jeremy Hylton wrote:
>>
>>>That's right.  The database only invokes conflict resolution on
>>>first-class objects, because it has no way to refer to the state of
>>>contained objects.  Second-class objects don't have identifiers (in
>>>other words, they're not first class :-).
>>
>>This isn't obvious to me.  If an OOBTree having string keys can
>>resolve conflicts, why not one having instances of my simple class as
>>keys?  In the former case, how does conflict resolution work without
>>the string objects having database identifiers?
> 
> The conflict resolution happens on the container (in the case of BTrees,
> the buckets), not the keys or values themselves.
> 
> So one way to get conflict resolution for 2nd class objects is to put
> them into a 1st class container that does the right thing about the
> conflicts.

Sorry, I had trimmed too much context from this thread.  That's exactly 
the case that is being discussed: keys of a BTree not being first-class 
persistent objects prevent the BTree conflict resolution from operating. 
  I'm not interested in conflict resolution between my keys.

-John


-- 
http:// if  ile.org/