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 org.apache.lucene.queryParser.surround.query 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 org.apache.lucene.search 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. Regards, Paul Elschot --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
