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 [EMAIL PROTECTED] 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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
