[ZODB-Dev] Using Catalog and BTrees

[Michel Pelletier]

On Tue, 22 May 2001, Greg Ward wrote:

> That how-to looks useful, but the author plainly states that the one
> line of code needed to make it work ("self.cat.aq_parent= self.root")
> is a hack and he's not sure if it's the right hack.  Have any ZODB
> insiders taken a look at this how-to to see if it's correct?

Haven't looked at it, but I can tell you that that is definately *not* the
way to assign your acquisition parent.  If you want to be wrapped in some
other objects acquisition context, you should say 'self.cat =
cat.__of__(root)' this will assign cat.aq_parent and all the other aq_
variables to the correct values.

Cataloging outside of Zope is hard yes, sorry about that.  It waws a hard
problem over all and at some point I sacrificed the modular design for
just getting it done.  Bad idea and I think I've learned my lesson (a bit
;).

But really in concept cataloging is not that hard, the heart of it are
BTrees, which are very independent of Zope.  Zope indexes are just
wrappers around different BTrees with code to index, unindex, query, etc.  
Zope indexes are complicated slightly by the fact that they store the 'old
values' for unindexing purposes in a reverse BTree since the object may
have be gone or no longer have the old values at unindexing time.

The catalog itself is just a wrapper around, and query aggregator for, a
collection of indexes.  

I think the problem with general indexes for ZODB is that everyone's
requirements are different.  For example, Zope's catalog uses paths to the
object for unique identifiers (eventually, you have to "get" to the object
you searched for).  Other system may, of course, not map paths to objects
and need to use some other unique identifier.  Some people may not need
the reverse BTree containing the old values because they have absolute
control of the data (ZTables used to do this, it kept its own data).

-Michel