> That's the official ZCatalog API. Otherwise find your objects through a catalog search and reindex them individually.
I already did the reindexing just before the search and it didn't work. In any case, I may have found a workaround by using getObject(). According to http://www.plope.com/Books/2_7Edition/SearchingZCatalog.stx#2-10 : getObject() Returns the actual zope object from the result object. This is useful if you want to examine or show an attribute or method of the object that isn't in the metadata--once we have the actual object, we can get any normal attribute or method of it. However, be careful not to use this instead of defining metadata. Metadata, being stored in the catalog, is pre-calculated and quickly accessed; getting the same type of information by using getObject().attribute_name requires actually pulling your real object from the ZODB and may be a good deal slower. On the other hand, stuffing everything you might ever need into metadata will slow down all querying of your catalog, so you'll want to strike a balance. A good idea is to list in metadata those things that would normally appear on a tabular search results form; other things that might be needed less commonly (and for fewer result objects at a time) can be retried with getObject. I tried it and it works. My code now looks like this : <code> wf = context.GeneralWorkflow cat = wf.Catalog jobs = cat.searchResults({'jobname':'ABC12345'}) for j in jobs: print j.getObject().jobname return printed </code> My only question now is ... How much slower is this solution than using the jobname metadata (assuming it worked). - Danny _______________________________________________ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )