[Zope3-dev] interaction between LocationProxy and IIntId utility

[Martijn Faassen]

Hi there,

We just noticed that some objects were not being cataloged correctly. 
After a lot of debugging, we noticed the following:

The IntId utility wouldn't find the unique id for an object when a 
modified event was sent. As a result, it wasn't being indexed.

We figured out that there was an odd difference between the object that 
came into the IntId utility (through a modification event) and the 
object that we could take from the folder: the one taken directly from 
the folder has a __name__ and __parent__. Even though the memory address 
looked the same when using repr(), they were not identical. As a result 
the int id couldn't be found.

Finally with some help from Stephan Richter giving us the clue that this 
__name__ and __parent__ information could only be lost if LocationProxy 
is in play, we figured out what what we think is going on:

What is stored in the ZODB are LocationProxy wrapped objects. The 
location proxy wrappers get a unique id reference in the IntId utility, 
not the objects themselves. Now when you send an ObjectModificationEvent 
from one the document's *own methods*, the event is sent with as payload 
to catalog something that is not proxy wrapped. This means that the int 
id can never be found for this object, and thus the reindexing cannot 
take place properly.

This basically means that LocationProxy wrapped objects cannot reliably 
respond correctly to ObjectModificationEvents, and thus won't be 
cataloged correctly. If the ObjectModifiedEvent is sent by methods 
inside the object itself, things will fail, if the ObjectModifiedEvent 
is sent by code elsewhere, they'll likely work.

This is all fixed by subclassing Contained, but the catalog not working 
reliably for LocationProxy wrapped objects sounds scary. You could do 
something with the IntId utility automatically 
un-location-proxy-wrapping the objects if necessary, but that would mean 
that what is stored wouldn't know its location anymore, which would also 
be bad.

Regards,

Martijn