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: http://search.cpan.org/~karman/Search-Query-0.18/lib/Search/Query/Dialect.pm#walk(_CODE_) > >> 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/Lucy.pm. 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 glue. -- Peter Karman . http://peknet.com/ . [email protected]
