[Zope-dev] ZCatalog peculiarities?

[Michel Pelletier]

> -----Original Message-----
> From: Phillip J. Eby [mailto:pje@telecommunity.com]
> Sent: Saturday, August 07, 1999 12:01 PM
> To: zope-dev@zope.org
> Subject: [Zope-dev] ZCatalog peculiarities?
> 
> 
> First, in Catalog.py, it seems like virtually every method of 
> the Catalog
> class calls self.useBrains().  useBrains() creates a new 
> class each time
> it's called, and then deliberately creates a circular 
> reference in that
> class, such that it can't be deleted.  Finally, the logic of where
> useBrains() is called, is such that it will be called once 
> for every item
> retrieved from every search done on the catalog.  Thus, every 
> record should
> end up as an instance of a different class, specifically 
> created for that
> record.  This has me baffled, because I can't see why that would be
> something useful.  Am I missing something really deep here, 
> or is it just a
> bug?  It would seem to me that there should be something like
> "_v_brains_inuse =_v_brains" at the end of the useBrains() 
> method, so that
> at the beginning you can check for whether "brains is 
> _v_brains_inuse" and
> skip creating a new class, etc. once the brains are initialized.

A fix for this is checked in.  useBrains is only called in the __init__,
__setstate__, addColumn and delColumn.  The circular reference is
removed.  This should be the correct behavior.  The current brains
machinery is just a placeholder for the new brains machinery (probably
in 2.1), which will be based on what ZSQL methods do.  In fact, they
will probably share the same code and have the added bonus of allowing
you to select a ZClass as a pluggable brain.  This means you can
construct a ZClass that defines the objects that get returned by the
Catalog (or an SQL Method).  This would be pretty cool.

> 
> The next thing I've noticed, is that Catalog.py imports from 
> Query, but
> then never actually uses anything from it.  Oh, sure, there's 
> an orify()
> function that does stuff, and a query_map local variable set up in
> searchResults() that references orify, but query_map never 
> gets used.  (And
> ZCatalog.py makes up another copy of the same query_map 
> object and passes
> it in, but that never gets used either.)  I even dug down to 
> Index.py and
> TextIndex.py to make sure query_map wasn't used down at that 
> level, and
> then I realized that query_map wasn't part of the namespace 
> being passed
> down there anyway.  This all looks like some sort of 
> vestigial leftovers,
> perhaps during porting from ZTables...?
> 

I'm going to leave this for now, think of it as the Zope equivalent of
an appendix.  I don't know what will happen if I take it out, and it's
not doing any damage or causing any memory leaks or slowdowns or
anything.

> The third thing I saw, is that there are lots of constructs 
> of the form:
> 
> if something in somethingelse.keys():
> 
> where the object 'somethingelse' appears to have a perfectly 
> good has_key()
> method available.  Again, is there some sort of deep Zen 
> here, like trying
> to force index pages to be loaded, or...?  I mean, it seems 
> like this would
> be much less efficient than just hitting the has_key() methods.
> 

These have been fixed, and will be in the final.

> Last, and definitely least, I notice that useBrains() uses a 
> loop to create
> scopy, when "scopy=self.schema.copy()" would suffice.  That 
> wouldn't be
> anything worth 'fixing', except considering how often that code would
> appear to be being called.
> 

Fixed.

-Michel