Part of the problem here is that if, in particular, you use the reindex_object method of CatalogAware, the database will grow unnecessarily even if the object hasn't changed. CatalogAware is arguably broken and should really not be used. I'd like to have the time to fix it, but fixing it implies taking time out that I don't have at the moment to test the changes, and *may* imply breaking it in slightly other backwards-incompatible ways that will cause people to scream. For instance, unfortunately, CatalogAware also uses the *url* of the object to index it, which is contrary to the way that newer Catalogs work (they index the physical path of the object). In the meantime, if you care at all about cataloging, do not use CatalogAware. Instead, manage the recataloging yourself and don't uncatalog a changed object before recataloging it during this manual operation, because this defeats all of the carefully set up change detection code (which may or may not still be working since I last worked on it ;-) - C Erik Enge wrote:
(I removed <zope@zope.org>.)
On Mon, 25 Jun 2001, Giovanni Maruzzelli wrote:
Any hints on how to manage something like? We use both textindexes, fieldindexes, and keywordsindexes (textindex on string properties, fieldindexes on boolean and datetime, keywordindex on strings). Maybe one kind of indexes is to be avoided?
Erik, any toughts?
Well, after ChrisM told me about the behaviour of CatalogAwareness, and I removed that from my classes, my ZCatalog bloatness has evaporated. I really can't see any major bloat-problem on either memory-consumption or disk-space. (That was with Zope 2.3.2b2.)
Which is very good for me, but doesn't necessarily help you much. :)