[Zope-dev] Re: Zcatalog bloat problem (berkeleydb is a solution?)

[Chris McDonough]

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.  :)