[Zope-dev] Catalog improvements

Wolfram Kerber wk@gallileus.de
Wed, 28 Nov 2001 08:30:17 +0100


Hi

No, i wasn't aware of your product :-( , the only one i found was ZOQL by
Stephan Richter, but that didn't help much. Well, now i have written an
implementation that reuses some of the code in TextIndex (for parenthesis
parsing and insertion of a default operator) an then saves the query in RPN
format (so the Catalog does't need to think that hard when being queried).
I have taken a look at your product, and i'd say a 'new' Catalog should have
sort of QueryParser plugins that know how to turn string-queries (as yours)
or SQL to native Catalog queries ...
I've also contacted the authors of the two proposals, just wasn't sure
wether i should start this off, since i have no experience as to how the
fishbowl works and i'm expected to finish my current project sometime soon.


Wolfram

----- Original Message -----
From: "Casey Duncan" <c.duncan@nlada.org>
To: "Wolfram Kerber" <wk@gallileus.de>; <zope-dev@zope.org>
Sent: Tuesday, November 27, 2001 2:48 PM
Subject: Re: [Zope-dev] Catalog improvements


> On Tuesday 20 November 2001 05:35 pm, Wolfram Kerber allegedly 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
> >
> > - caching support
> >
> > - unions and intersections
> > sub-queries (i.e. queries that are directed at a certain index) should
be
> > more flexibly combineable
>
> I have some code that implements this in my CatalogQuery product. It
creates
> a query object from a string. Presently these are not persistent, but they
> could easily be made to be to create precompiled queries.
>
> code at: http://www.zope.org/Members/Kaivo/CatalogQuery
>
> >
> > I searched this mailing-list as well as zope.org to get an idea about
what
> > has already been discussed and requested, and there seems to be some
> > interest in improving the Catalog. Some people even seem to have worked
on
> > this, perhaps they could give an update on this? Possibly i don't have
to
> > write everything from scratch...
>
> I would be willing to help both in coding and getting the code put into
the
> Zope core.
>
> > I would have put this into a proposal, but there already are two
proposals
> > that deal with the features i want, one is dedicated to
> > unions/intersections, the other (TopicIndexes) to performance issues (i
> > dont't know what's the status of these though, especially the first one
is
> > rather old), and i don't want to hijack them without asking. As so often
i
> > will need to complete my current project first, but would then like to
help
> > in improving the Catalog for a more general use.
>
> Possibly we need to rekindle discussion. I would suggest contacting the
> authors of those proposals to see how compatible your concepts are wth
> theirs. Perhaps a new proposal should be drafted with the new ideas and ty
> them back to the previous ones. If there is redundancy, that can be worked
> out.
>
> >
> > So, if there is interest, i would propose to collect some ideas and
> > comments about how a better Catalog should look like, how it could be
best
> > implemented and how to organize this effort (with respect to the already
> > existing proposals).
>
> I am very interested in such a discussion. Let me know what I can do to
help.
>
> /---------------------------------------------------\
>   Casey Duncan, Sr. Web Developer
>   National Legal Aid and Defender Association
>   c.duncan@nlada.org
> \---------------------------------------------------/