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