This is mostly a question for AJ, but any input would be great. This bug bit me today and is documented here: http://collector.zope.org/Zope/449/ISSUE_TRANSCRIPT/view I dont understand the brief argument against this one, it would make sense to me to able to pull an object out of the catalog based on its path. For example if I want /foo/bar/blammo, currently this means there is only one way of pulling the an object of the catalog given this path. Thats to send (path='/foo/bar', id='blammo'), rather than (path='/foo/bar/blammo'). Why wouldnt we want it this way? One thing I have done is store a whole bunch of references to objects as selected by the user. These are essentially random objects and the quickest way is to pull them back out of the catalog. Of course I cant do more than one object per query (unless Im missing some other way) Id love to do (path=['/foo/bar/blammo', '/foo/bar/blammoz']) and get these 2 objects... I think that would be neat. It would seem data_record_id_ is not guaranteed to permanent after a reindex_object (which CatalogAwareness uses), since this uncatalog and then recatalogs the object. If this did work it would be cool and I could undo all the changes to my app back again. - The patch is already there, so Im curious why do we have what seems to be a more limited design? - Would a halfway option such as path_match='final' be a choice that wont break any code but would confuse everyone and not make into the documentation? - Is it just a matter of fixing reindex_object as was suggested on #zope so that data_record_id_ is more permanent? Cheers -- Andy McKay Agmweb Consulting http://www.agmweb.ca