Casey Duncan wrote:
 > For eternity, ZCatalog has, when instantiated, created a set of
 > predefined indexes and metadata. Back in the day when we had only
 > three index types, this made some sense. Also, some of the indexes
 > were less than useful. For instance, bobobase_modification_time is
 > really too low level to be used for what the Catalog suggests we use
 > it for. Summary only exists in CatalogAware objects, etc. etc. Now
 > that we have plug-in indexes, it makes even less sense to guess what
 > people are going to use their catalogs for.

Excellent.  A lot of catalog-driven sites have trouble keeping the size
of Data.fs down, and often the source of the problem is the catalog
indexes and metadata fields left in place but never used.

 > The current code in the trunk no longer populates the ZCatalog with a
 >  predefined set of indexes or metadata. It is up to the user or
 > application to do this now. Realizing that some products may rely on
 > this behavior, I am sending this warning so that you have an
 > opportunity to test it for yourself.

Currently, CMF falls under this category. :-(

 > Another anachronism in the Catalog was that it automatically created
 > and maintained a reference to a Vocabulary/Lexicon object to be used
 > by the TextIndexes. Now that we have 3 different kinds of TextIndex
 > available, one of which (ZCTextIndex) does not even use the same type
 > of lexicon objects, this makes no sense anymore. Besides the fact
 > that TextIndex already can manage its vocabulary association by
 > itself anyhow.
 >
 > So, I have removed the dependency of Catalog on Vocabulary. Catalogs
 > no longer store a reference to or care about vocabularies. Also,
 > vocabulary objects are not created or chosen when instantiating a new
 > ZCatalog. Like with indexes, this is now up to the user or
 > application code.

I was happy when you told me this yesterday, but now that I've thought
about it, I'm ecstatic. ;-)  I once tried to dezopeify ZCatalog, and the
vocabulary stuff was a major hurdle.  (The next hurdle is acquisition,
should we pursue this avenue further.)

Shane



_______________________________________________
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )

Reply via email to