[Zope-dev] ZCatalog, REQUEST, misc.

[Chris McDonough]

> > Why CatalogAware?  You do know that the only thing CatalogAware does
> > is add/remove/reindex objects in one particular Catalog when they're
> > added, removed, or changed?
>
> Yes, and this is all I need.  Where is the overhead with CatalogAware
> objects, then?

Any time a parent object is deleted or moved (or the object itself is
moved), all the objects inside of it which are CatalogAware will then
blissfully reindex themselves with the catalog.  If you move a folder full
of these things, you'll potentially wait hours for the copy to happen.

Additionally, each of the
manage_afterAdd/manage_afterClone/manage_beforeDelete methods of a
CatalogAware objects iterates over the results of self.objectValues() and
calls the respective methods on each of their subobjects (if you don't
define objectValues for your noncontainerish object or if you don't inherit
simpleitem, you'll be in a world of hurt).

Additionally, the reindex_object method of CatalogAware (if you ever call
it) is completely redundant and badly inefficient at this point, because it
just calls unindex_object and index_object of the cataloged object.
Versions of the Catalog as of late make this a very bad thing, because
they're quite careful about only reindexing things which have changed, thus
only catalog_object should be called.

Also, the current CatalogAware uses nonvirtualhost-aware URLs as Catalog
uids (absolute_url as opposed to getPhysicalPath) which might bite you if
you're using virtual hosting.  If this is important to you, you could try
using "CatalogPathAware" which is CatalogAware updated to use virtual-host
aware paths.

All you need to do as a part of your code when not using CatalogAware is:

YourCatalog.catalog_object(newobject)

as opposed from inheriting from CatalogAware and relying on manage_afterAdd
or calling object.index_item() manually.  That's really it.

The incremental-change stuff and remove-from-catalog-on-delete stuff
provided by CatalogAware is currently inappropriate for large numbers of obj
ects when moving, deleting, or renaming containers (it's fairly DWIM-ish as
well) because of the assumptions it makes about time-to-unindex/reindex.
This will hurt you in the long run.

Both CatalogAware and CatalogPathAware need to be fixed somewhat (they need
to be replaced with an observer-based cataloger).  This is probably my fault
at this point, but don't say I didn't tell you not to use them later.  ;-)

- C