[ZODB-Dev] persisting "immutable" classes

[John Belmonte]

Jeremy Hylton wrote:
> 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?

OK, so it's back to that issue-- that seems a bit more reasonable.

When I change nothing other than making JobKey derive from Persistent, 
there is no unpickling problem during conflict resolution.  So is 
Persistent doing anything fancy to help locate JobKey?  Registering the 
class somewhere?

-John


-- 
http:// if  ile.org/