[Zope-dev] Catalog improvements

[Wolfram Kerber]

----- Original Message -----
From: "Jeffrey P Shell" <jeffrey@cuemedia.com>
To: <zope-dev@zope.org>
Sent: Wednesday, November 21, 2001 7:38 PM
Subject: Re: [Zope-dev] Catalog improvements


>
> On Tuesday, November 20, 2001, at 03:35  PM, Wolfram Kerber wrote:
>
> > Hi,
> >
> > i'm currently working on a product that allows to attach relational
> > information to zope-objects. It works quite well so far, but to further
> > enhance it i need to make some changes to the Catalog. I could perhaps
> > implement it as a separate product, but i strongly feel that those
> > changes
> > are best applied to the Catalog itself, as they are of general use
> > (i think)
> > and involve a lot of changes to the inner workings of the Catalog. In
> > particular i need the following:
> >
> > - named/stored queries
> > these are precompiled queries, so they can be executed without
> > parsing and
> > are easily cacheable
> > i.e. similar to what is implemented in CMFTopic, but stored in the
> > Catalog
> > and a bit smarter
>
> There used to be something like this in ZTables/Tabula (a Zope 1.x
> product that was sort of the genesis of the Catalog, for better or
> worse) called 'Hierarchies'.  Hierarchies were actually indexes (I
> think the current Keyword index is descended from the Keyword
> Hierarchy).
>
> I don't know what happened to that code.  If it's not available,
> you could probably achieve the effect that you're looking for here
> with PluginIndexes

I think your right. Indexes also have a management interface that could be
used to define the query. It could result in a nesting problem however, if
'QueryIndexes' rely on each others results (that they should be able to). I
would possibly need a management view that shows the hirarchical structure
of the Indexes, but it can be merely that, a view.
I'll try this out...

>, which wouldn't require changing the Catalog at all.

I'd say, if  i would _not_ store the result of the query and just delegate
to other indexes this would be true, otherwise i would need some notify
mechanism to tell if my result is affected by an indexing call, and/or at
least be notified when the call is over so i can update the result by
issuing a query, but the latter would mean to 'take the big hit' as you
mentioned, wich i think isn't acceptable.

> Just write a "Query Index" that indexes objects that match
> its pre-cooked Query.  This would speed up searching tremendously,
> but you could take a big hit at indexing time if you have many of
> them.
>
> Jeffrey P Shell, jeffrey@cuemedia.com

thanks,

Wolfram