lucy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Karman <>
Subject Re: [lucy-user] Question about query parsing API
Date Tue, 01 Mar 2011 03:20:46 GMT
Andrew S. Townley wrote on 2/26/11 6:55 AM:

> At the very least, I need to be able to walk the query tree for any string
> input query (or any query object) with a consistent API.  What you have here
> is pretty similar to my own implementation of the Query Object pattern for my
> system, so that would be a start.  For any compound query term, I'm also
> "bubbling" up references to the property names as well as the query terms
> themselves.  This means that I can retrieve these easily and do some analysis
> on the query before actually executing it.
> Anything that will support me doing the same type of thing with Lucy will
> work.

It's not core to Lucy, but Search::Query::Dialect has a KSx (KinoSearch
extension) implementation that makes it easy to walk the tree:

>> There are portions of Lucy that have been intentionally left unimplemented
>> by the core.  The Perl implementation code is located in trunk/perl/xs/
>> and trunk/perl/lib/  This code will have to be ported for each new
>> host language regardless.
> Interesting approach.  Is there some docs/rationale on which parts and why
> somewhere?  Sounds worth understanding in more detail.

Marvin can answer as to whether there are docs on this; my understanding of the
rationale is that since our goal is idiomatic language implementations on top of
the underlying C, each host language must do *some* work.

Lucy isn't a C library in the traditional sense; it's more like a
some-assembly-required C framework for writing an IR library in a dynamic
language. The C code handles the heavy-lifting bits that are too
resource-intensive to be practical in the host language. Then each host language
must glue it all together. Clownfish provides a way of generating (most of) that

Peter Karman  .  .

View raw message