lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Elschot <paul.elsc...@xs4all.nl>
Subject Re: Query.extractTerms - a poor introspection API?
Date Thu, 06 Apr 2006 17:19:31 GMT
On Thursday 06 April 2006 18:53, Yonik Seeley wrote:
> On 4/6/06, mark harwood <markharw00d@yahoo.co.uk> wrote:
> > Maybe we should have as a standard part of Query:
> >
> >   //immediate child queries only
> >   Query [] getNestedQueries();

This is another way to deal with composed queries:
http://svn.apache.org/viewcvs.cgi/lucene/java/trunk/contrib/surround/src/java/org/apache/lucene/queryParser/surround/query/ComposedQuery.java?rev=209183&view=log

In surround, this is the superclass for all queries that have an operator and 
subqueries.

> 
> It's still the case that you often need to know what type of query the
> parent is.
> For example, a BooleanQuery with mandatory, optional, and prohibited 
clauses.
> Or, as Marvin brings up, phrase queries, etc.
> 
> One may not want to worry about terms that don't match when constrants
> are applied (like a phrase) to begin with, but you don't want to
> implement it in such a way that makes it hard to add later.
> 
> IMO, the query hierarchy should be fully self-describable... user code
> should be able to walk it and re-create the exact same thing if
> desired.

There is a visitMatchingTerms method here:
http://svn.apache.org/viewcvs.cgi/lucene/java/trunk/contrib/surround/src/java/org/apache/lucene/queryParser/surround/query/SimpleTerm.java?rev=209183&view=log

This is the superclass for the term queries such as truncated terms.

Regards,
Paul Elschot

---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org


Mime
View raw message