Hi all,

zope.catalog is a crucial part of ZTK, as it adds the equivalent of
RDBMS SELECT queries to our ODB based apps.  However in my opinion its
default setup is suboptimal as a generic library in ZTK, because it is
hardwired up for ZMI "point and click" operation.  As soon as you
create and register an ICatalog utility, every ObjectAddedEvent and
ObjectModifiedEvent will trigger stuffing the object into intids, and
each intid registration event will trigger an attempt to index an
object.  When you add an index to the catalog, it gets reindexed
automatically.  Because these behaviours are implemented by event
handlers, there is no way for an app to override or disable them.

There is an "opt out" mechanism for keeping objects out of the catalog
(INoAutoIndex, INoAutoReindex marker interfaces), but curiously the
latter does not inherit from the former,so your object can be indexed
on modification even if you made it provide INoAutoIndex.

Automatically stuffing all newly added objects into the int ids
utility and then further into the catalog is bad, because, first, it
cripples any alternative uses of the int ids utility, turns it into
purely a catalog accessory, and second, places some restrictions on
containers and contained objects due to the persistent oid based key
reference implementation.

About a year ago zope.app.catalog as been moved to zope.catalog.  I
think during this move there was a unique opportunity to leave these
event handlers behind in zope.app.catalog, so that the "no .app"
version is free of these forced choices.  But perhaps it's not too
late to do in now?  After all, no stable version of Zope 3 / ZTK
codebase has been released after this move?  People relying on
automatic indexing would have to register a couple of event handlers
in their configurations (or include zope.app.catalog), but the rest of
us would be able to choose the policy of how and when the objects are
registered with IntIds and indexed in the catalog.

http://www.pov.lt/ -- Zope and Python consulting
Zope-Dev maillist  -  Zope-Dev@zope.org
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope )

Reply via email to