lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Elschot <>
Subject Re: Query modifier
Date Fri, 16 Dec 2005 21:41:08 GMT
On Friday 16 December 2005 11:42, Erik Hatcher wrote:
> In my latest project, I've written code to walk a general Query and  
> do three different manipulations of it: 1) Convert it to a SpanQuery  
> 2) Change a specified field to another field for each nested Query 3)  
> Rotate (Span)RegexQuery terms.
> I have a lot of duplication of this recursive Query processing.  I'd  
> like to create a general way to do this sort of thing and am  
> wondering if others have created similar routines and  have ideas  
> that might be useful in making a general facility.

Have a look in the contrib/surround package
class.method : ComposedQuery.makeLuceneSubQueriesFIeld(),
this calls the method makeLuceneQueryField on each sub query
and collects the results.
Each ComposedQuery implements makeLuceneQueryField
by using makeLuceneSubQueriesField. Non composed queries
just implement it this without this recursion.

> I'm also curious if there are changes to Query that could be made to  
> facilitate this sort of thing, such as setters to allow terms to be  
> changed without having to construct an entirely new TermQuery for  
> example.  I realize that Query's are considered basically immutable,  
> and maybe this is an important thing to maintain, or maybe this  
> convention is worth abolishing?

There is no real point in avoiding the creation of a few more query
objects when this is followed by a query search in a non trivial index.
Query searching creates quite a few small objects to collect
document scores for documents that score high enough to be
kept in a Hits object.

BooleanQuery has an add() method, so it is not immutable.
In the surround parser queries are constructed bottom up
during parsing by passing all the subqueries to the constructor.

One could add something like ComposedQuery 
to the queries in to support recursion
over composed queries.
A general facility would need a visitor pattern, and that
may not be worthwhile for a single purpose.

There is  no visitor pattern like this in the surround parser,
because there the only real purpose of visiting is to create
lucene queries.
There is also a recursive toString() implementation in
this ComposedQuery.

Paul Elschot

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message