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

[Chris McDonough]

Eric Roby wrote:
> 
> Chris McDonough Wrote:
> > CatalogAware is arguably broken and should really not be used.
> 
> > 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 ;-)
> 
> Chris,
> 
> Thank you for your candor here.  I wish this minor detail had been disclosed
> in the Zope book.  Chapter 9 was my holy grail when I started down this
> trail (creating these new ZClasses that would auto catalog themselves).  It
> looked good in print...  I have banked a good deal of my project on this
> very service and ... well it is a bit frustrating to find out that I need to
> go back and re-do my work.

Well.. actually, it's pretty simple to change CatalogAware to work
better for you.  
With a little thought, CatalogAware could be hacked at your end to be
sane for your application.  You needn't rewrite all your code.  It's
just hard for DC to release a perfect CatalogAware that works better and
is completely backwards-compatible.  It's much harder to change it to
work perfectly for everybody (which is our job here ;-) than to change
it to work perfectly for a particular application.

Basically, change the reindex_object method to:

  self.index_object()

Instead of:

  self.unindex_object()
  self.index_object()

That makes CatalogAware much saner and will produce less bloat. 
Actually, maybe I should just go make that change in the trunk and the
2.4 branch, although I'm a little afraid of what (if anything) it will
break for everybody.  To be honest, I really don't have much time to
spend thinking about this, and my fears are probably just FUD.

> Along this same vein,  I would suggest that (possibly) ZClasses don't really
> work, either, "and should not be used".  There was a comment from another
> developer (on zope-dev a month or so ago) that essentially (in his own
> words) made this very claim.  At the time, I chalked it up to this "Real
> Zope Developers Don't Use ZCLasses" kinda comment.  There certainly are
> enough Zope products out there that (at least) leverage some of the ZClass
> plumbing.

Well, I dont use ZClasses much.  But that's because I like to use Emacs.
 
> Another claim in the Zope book (chapter 8) says that I can leverage my 6+
> years of Perl experience to create Zope scripts.  Well, I would suggest that
> this doesn't really work, either...

Not sure what you mean by doesnt work, but I assume you've had an
unpleasant experience with zope-perl?
 
> The bottom line to all this venting (and I am not trying to shoot the
> messenger here) is that I need to understand where my efforts should be
> focused.  If I need to abandon ZClasses in lieu of pure Python, then I need
> to know that now so I don't waste any more time on these false starts. The

I'll go out on a limb here.  You should learn how to write Python
Products if you're serious about creating reusable Zope applications. 
There.

> Perl thing is just a matter of principle (I think Perl's implementation of
> OO stinks).  The way it is presented in the book, I would expect it to be a
> core Zope thing and not some appendage that requires a particular compiler
> and Andy sitting next to you.

I've sort of enjoyed myself on all the times when Andy has been sitting
near me, but I understand.  ;-) Jim had a bad experience installing
zope-perl lately.  I wish I could help.  Strangely, myself, I had few
problems getting it installed and working fine.  Maybe I'm just lucky. 
I actually think zope-perl is sort of an engineering marvel myself.
 
> I don't intend to abandon Zope, I just need a reality check...

HTH,

- C