[ZCM] [ZC] 167/ 1 Request "ObjectManager.superValues() ignores some objects it shouldn't"

[Collector: Zope Bugs and Patches ...]

Issue #167 Update (Request) "ObjectManager.superValues() ignores some objects it shouldn't"
 Status Pending, Zope/bug+solution medium
To followup, visit:
  http://collector.zope.org/Zope/167

==============================================================
= Request - Entry #1 by LRA on Jan 22, 2002 1:52 pm


Uploaded:  "ObjectManager_superValues.patch"
 - http://collector.zope.org/Zope/167/ObjectManager_superValues.patch/view
The ObjectManager.superValues(self, t) method (which climbs the aq_parent chain looking for objects with meta-types listed in the tuple t) stores the objects it finds in a dictionary so as not to store duplicates.

However, the way it stores the found objects in the dictionary is by their IDs, which means that two objects that have the same ID but are in different points of the tree don't get both included.

For example, the following tree list objects with their IDs and (in parenthesis) their meta-types::

 FolderA (Folder)
  |
  +--- objectA (MetaTypeT)
  |
  \--- FolderB (Folder)
        |
        +--- objectA (MetaTypeT)
        |
        \--- objectB (MetaTypeT)

In the above tree, the call to::

  FolderA.FolderB.superValues(('MetatypeT',))

Will return::

 [ FolderA.FolderB.objectA, FolderA.FolderB.objectB ]

Instead of::

 [ FolderA.FolderB.objectA, FolderA.FolderB.objectB, FolderA.objectA ]

This happens because the 'seen' dictionary cannot allow the inclusion of two 'objectA' in it.

The included fix solves the problem by keying the 'seen' dict by the found objects physical path. It does this in a non intrusive way, calculating each physical path without querying the objects directly, so it's performance should be very close to the original.

==============================================================