[ZODB-Dev] persisting "immutable" classes

[John Belmonte]

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:

   2004-03-01T13:12:42 ERROR(200) Conflict Resolution Unexpected error
   Traceback (most recent call last):
     File 
"/usr/local/lib/python2.3/site-packages/ZODB/ConflictResolution.py", 
line 96, in tryToResolveConflict
       newstate = unpickler.load()
   AttributeError: 'module' object has no attribute 'JobKey'


-John


-- 
http:// if  ile.org/