[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:
> 
>    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'

I think I misunderstood your question.  The conflict resolution code is
plain-old Python code.  It can use whatever classes you want to use, but
you have to be sure that the code for those classes is available on the
server.  It looks like the unpickler is failing the find the JobKey
class.  Are you sure that code is available on the server?

Jeremy