I love hurry.query. Whether it's in the core or not doesn't phase me, but it is really really helpful. We got bit by not realizing that FieldIndex queries passed directly to the catalog/index had a low and high range. It was a small bite. But it took us a while to figure out why searching for 'summer' pages included 'winter' ones, but searching for 'winter' pages only returned winter. So we put in hurry.query. And were able to do it without depending on zc.catalog. It made the catalog experience a lot nicer.
I'd put my vote behind inclusion. While the catalog is certainly cleaner and easier to understand than the Zope 2 catalog, querying it is still kindof a pain, which is mentioned in zope.index.interfaces.IIndexSearch TODO This is somewhat problemetic. It means that application code that calls apply has to be aware of the expected query type. This isn't too much of a problem now, as we have no more general query language nor do we have any sort of automatic query-form generation. It would be nice to have a system later for having query-form generation or, perhaps, sme sort of query language. At that point, we'll need some sort of way to determine query types, presumably through introspection of the index objects. hurry.query seems to fill in this hole. On 10/24/05, Martijn Faassen <[EMAIL PROTECTED]> wrote: > Hi there, > > Would there be any interest in merging hurry.query into Zope 3.2? > > What it does: > > hurry.query - higher level query system built on top of the Zope 3 > catalog. Some inspiration came from Dieter Maurer's > AdvancedQuery. See src/hurry/query/query.txt for > documentation. > > Here's the code: > > http://codespeak.net/svn/z3/hurry/trunk/src/hurry/query/ > > And here's a doctest: > > http://codespeak.net/svn/z3/hurry/trunk/src/hurry/query/query.txt > > Of course, it probably needs a review and adaptations before it's > accepted, and time until the feature freeze in november is short. It > would be a very useful addition to Zope 3's featureset, however. It > exposes features of various indexes that the normal catalog API does not > expose, or if so, only very obscurely. :) Now that I think of it, > exposing the ZCTextIndex properly with the various features involved may > need the most work. > > If there's interest, I'd really appreciate volunteers for putting up a > proposal on the wiki and integrating it into the codebase. This way it'd > get a review by that person. If it'd be up to myself I likely won't have > time... > > By the way, is zc.catalog up for merging with Zope 3.2, or won't this > happen yet? hurry.query has a dependency on zc.catalog, though I believe > I succeeded in keeping this optional. > > Regards, > > Martijn > _______________________________________________ > Zope3-dev mailing list > Zope3-dev@zope.org > Unsub: http://mail.zope.org/mailman/options/zope3-dev/eucci.group%40gmail.com > > _______________________________________________ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com