I've identified the bug with the second issue, double-calling of unindex_object. First, the problem:
When deleting through the SMI a container structure like:
/f
/f/f1
There will be an error like:
2008-02-29 22:29:20 ERROR Zope.ZCatalog uncatalogObject unsuccessfully attempted to uncatalog an object with a uid of /silva/f/f1.
Using a trial version of the WingIDE, I debugged this (which was sweet!), and found out that with the Zope 3-based events, lib/python/OFS/subscribers.py function dispathObjectWillBeMoved event recursively iterates down the to-be-removed (in this case removed) objects items and runs the events subscribed for each sub-item. Once that is finished, it calls the items manage_beforeDelete subscriber.
The objects manage_beforeDelete method, in Products.ZCatalog.CatalogPathAwareness.CatalogAware.manage_beforeDelete, first unindexes the item (in our example, '/f'), then iterates over all children, calling their manage_beforeDelete methods.
So really, now that we're in Zope3 event land, this CatalogAware.manage_beforeDelete doesn't need to iterate over children. Commenting out the children iterator loop fixes this error.
So now my next question: what are the next steps to getting this bug fixed in Zope? And most likely, the other manage_* methods in CatalogAware need to be similarly rewritten to remove the objectValues() loop.
I've identified the bug with the second issue, double-calling of unindex_object. First, the problem:
When deleting through the SMI a container structure like:
/f
/f/f1
There will be an error like:
2008-02-29 22:29:20 ERROR Zope.ZCatalog uncatalogObject unsuccessfully attempted to uncatalog an object with a uid of /silva/f/f1.
Using a trial version of the WingIDE, I debugged this (which was sweet!), and found out that with the Zope 3-based events, lib/python/ OFS/subscribers .py function dispathObjectWi llBeMoved event recursively iterates down the to-be-removed (in this case removed) objects items and runs the events subscribed for each sub-item. Once that is finished, it calls the items manage_beforeDelete subscriber.
The objects manage_beforeDelete method, in Products. ZCatalog. CatalogPathAwar eness.CatalogAw are.manage_ beforeDelete, first unindexes the item (in our example, '/f'), then iterates over all children, calling their manage_beforeDelete methods.
So really, now that we're in Zope3 event land, this CatalogAware. manage_ beforeDelete doesn't need to iterate over children. Commenting out the children iterator loop fixes this error.
So now my next question: what are the next steps to getting this bug fixed in Zope? And most likely, the other manage_* methods in CatalogAware need to be similarly rewritten to remove the objectValues() loop.