[Zope-dev] zope.app.keyreference adds IPersistent objects to connections inappropriately? (was: five.intid and DirectoryView)

[Ross Patterson]

In this discussion from another list, Tres suggested that the bug might
be in zope.app.keyreference so I'm copying this to the development list.

The gist here is that the IPersistent, IObjectAddded event handler will
force objects to have connections and makes assumptions about what
connection it should get that might not be valid.  Here's the thread:

http://thread.gmane.org/gmane.comp.web.zope.plone.product-developers/2309

Thoughts?

Ross

Ross Patterson <me at rpatterson.net> writes:

> Tres Seaver <tseaver at palladion.com> writes:
>
>> Martijn Pieters wrote:
>>> On Fri, Jun 27, 2008 at 6:53 PM, Ross Patterson <me at rpatterson.net> wrote:
>>>> "Martijn Pieters" <mj at zopatista.com> writes:
>>>>> But the code never does that. When cloning a file-based FSObject, a
>>>>> new instance is created and that is added to the ZODB. Noone else
>>>>> should do this either.
>>>> zope.app.keyreference does.  The persistence machinery doesn't add an
>>>> object to a connection until commit.  As such, an IPersistent and
>>>> IObjectAdded event handler, such as the one in zope.app.intid, that
>>>> needs the object to have a connection needs to add the object to a
>>>> connection.
>>
>> Sounds like a bug in zope.app.intid to me:  it shouldn't be forcing
>> objects to have connections.
>>
>>> Why is the IObjectAdded event fired at all? Perhaps that's the bug here.
>>> 
>>>> Shouldn't anything that implements IPersistent be able to be added to a
>>>> connection?  Wouldn't that be considered part of providing the
>>>> interface?  Where else is an object that provides IPersistent stored in
>>>> global state?
>>> 
>>> I assume it was easier at the time to use just one class. Perhaps this
>>> should be reconsidered now. However, just providing the IPersistence
>>> interface does not mean the object expects to be added to a connection
>>> arbitrarily.
>>
>> Exactly.  Nobody is supposed to add objects to a connection except their
>> already-persisted containers.
>
> That sounds right to me especially given that an object's parent isn't
> necessarily "where" the object is persisted.  Shouldn't it be possible,
> for example, to have a container that looks up it's contained items from
> a utility that actually is stored in another ZODB.  Such a container's
> items would not share their parent's connection.
>
> FWIW, this happens in zope.app.keyreference.  The reason it needs the
> object to have a connection is so that it can get the object's _p_oid.
> If this is a bug, how can zope.app.keyreference get _p_oid for an object
> added in the current, as yet uncommitted transaction?
>
> Ross
>
> _______________________________________________
> Zope-CMF maillist  -  Zope-CMF at lists.zope.org
> http://mail.zope.org/mailman/listinfo/zope-cmf
>
> See http://collector.zope.org/CMF for bug reports and feature requests