[ZODB-Dev] persisting "immutable" classes

[Jeremy Hylton]

On Mon, 2004-03-01 at 13:33, John Belmonte wrote:
> I wrote:
> > My question was regarding immutable classes, where the "non-persistent" 
> > (in your words) object is never modified.  An example would be a class 
> > representing a time+ID tuple that has total ordering, for use as a key 
> > in a BTree job queue.   I'd like to know in this case if there are any 
> > other issues I should be aware of.  Also I'd like to know what kind of 
> > space overhead there is in deriving from Persistent, and whether doing 
> > so negates the savings I get by defining slots.
> 
> I think I've uncovered another limitation of second-class persistent 
> objects.  They cannot be involved in the conflict resolution of some 
> other first-class object.  For example, when trying to use a 
> second-class persistent JobKey as a key of a BTree container, I get the 
> following error from the ZEO server during BTree conflict resolution:

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 :-).

Jeremy