[Zope3-dev] interaction between LocationProxy and IIntId utility

[Jim Fulton]

Martijn Faassen wrote:
> 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.

I think you mean ContainedProxy 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.

I think what's happening is that ContainedProxy objects are persistent and
thus get a key reference, and this an intid that is distinct from the object
they proxy.

> 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,

which avoid the ContainedProxy.

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

I'm a bit puzzled that your content object's methods are geberating
modification events.

If an object doesn't participate in the location framework, then we have to
create a second object that provides location, the ContainedProxy.
There are really two distinct objects.  You want the intid to point to
the proxy, so you get the location information.  The content object knows
nothing about the proxy, so it can't generate events about the proxy.

My suggestion is to do one of:

- Implement ILocation in your content objects.  This is the
   simplest course. It sounds like, for your application, the content
   objects should know about their locations, since you want them
   to be able to generate events that contain location information.

   or

- Don't generate events amout the located objects (e.g. modification
   events) from within content object methods. The content objects
   don't have enough information. Rather, generate the events from views
   on the objects obtained from the container.

Jim


-- 
Jim Fulton           mailto:jim at zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org