lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Erik Hatcher <>
Subject Re: Query modifier
Date Mon, 19 Dec 2005 21:11:37 GMT
Chris and Paul - thanks to you both for replying on this.

Paul - I keep forgetting about the goodies hidden in the Surround  
parser.  I'll take another look at them soon.

Chris - I think your code would be good to see as a contribution  
candidate for the contrib area.  QueryFilter definitely needs to  
change as a name, I agree!  :)  What I'm aiming for is the Visitor  
pattern of a Query, and your implementation seems to fit that, so  
maybe "visitor" should be incorporated in the name somehow?   I'd be  
glad to see what you've done, if you're up for sharing it.


On Dec 18, 2005, at 2:32 AM, Chris Lamprecht wrote:

> Hi Erik,
> I ran into the same thing in my work so I created a query utility
> class and an interface called QueryFilter (I know this is a bad name)
> that is really more of a visitor pattern callback thing.  Most of my
> methods are convenience methods built on top of this interface and a
> few classes that implement it.  The main method in the utility class
> takes a lucene Query and a QueryFilter, and returns a (possibly new)
> Query object:
> public static Query filter(Query query, QueryFilter filter) {
>   /* typical recursive code to traverse the query if it's
>    * a BooleanQuery, or handle the terminal query
>    * base case, issuing callbacks to the QueryFilter
>    * interface.
>    */
> }
> Some of the utility methods I've build using this interface and  
> code are:
> /** Converts a query into a "sloppy phrase" query for a given field
> (optional) and slop */
> public static Query getSloppyPhraseQuery(Query query, String field,  
> int slop)
> /**
>   * Returns a Collection<String> of non-prohibited
>   * terms for a given query and optional field.
>   */
> public static List<String> getTerms(Query q, String field)
> /** flattens a query, allowing depth up to d; use d=0 for  
> completely flat. */
> public static Query flatten(Query q, int d)
> /**
>   * Returns an infix String from a {@link Query},
>   * optionally including the field in the query.
>   */
> public static String getInfixString(Query q, String field, boolean  
> includeField)
> If others find this useful, I'd like to submit it so the lucene
> developer community can help clean up the API for general consumption.
>  I didn't bother changing any existing Lucene code such as TermQuery;
> I haven't noticed any performance problems; I'm pretty sure the whole
> query parsing/rewriting phase takes less than 1ms (it registers 0ms..
> I guess I could use Java 1.5's nanotimer to get more detailed numbers
> :)
> -chris
> On 12/16/05, 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.
>> 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?
>> Thoughts?
>>        Erik
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message