lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Elschot <>
Subject Re: API cleanup: BooleanQuery.add()
Date Mon, 23 Aug 2004 18:45:37 GMT
On Monday 23 August 2004 19:38, Doug Cutting wrote:
> Daniel Naber wrote:
> >>BooleanQuery is really a misnomer, since it is not the traditional tree
> >>of boolean operators.
> >
> > Then maybe we should rename it for Lucene 2.0? Do you have a better name?
> Hmm... we could call it something like CompoundQuery, CombinedQuery or
> ComposedQuery, since it is the only primitive query type that combines
> other types of queries.

Those C...'s are perhaps too general, one could also see a SpanQuery
as C...'ed.
I was thinking about OccurrenceQuery or perhaps CombinedOccurrenceQuery.
But I can live with BooleanQuery.

> We could also add classes for true boolean queries, AndQuery, OrQuery
> and AndNotQuery, all of which rewrite to CompoundQuery.  AndQuery and
> OrQuery could be n-ary, rather than binary.  Would there be much point
> in this?

That would be nice for query languages having such facilities. 
It's difficult to combine the current query language with those operators,
at least for me it was when implementing the Surround language posted
earlier. One point of that language is this line of java code:

public class DistanceQuery extends ComposedQuery implements DistanceSubQuery

which is why I'm not in favour of using ComposedQuery for boolean purposes
only. Searching a DistanceQuery is implemented by a Lucene SpanQuery btw.

OTOH, in the Surround language ComposedQuery is not a subclass of
Lucene's Query, it only represents that the input to the query parser
consisted of some operator with subqueries/clauses.

Perhaps one should distinguish parsed queries (AndQuery, OrQuery etc.)
from searchable queries (BooleanQuery, SpanQuery) by
putting them in separate packages.

Paul Elschot

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

View raw message