lucene-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ted Dunning <>
Subject Re: operator precedence and confusing result
Date Fri, 13 Mar 2009 18:33:50 GMT
Actually, the nesting of BooleanQueries with required, optional and excluded
clauses are equivalent in power to (), AND, OR and AND-NOT.  Any expression
in one form can be expressed in the other.  Moreover, the Lucene form allows
very nice intepretation with relevance scoring that is difficult with the
normal Boolean expressions.

The only thing you need to have is an accurate translation.  No need to
remove anything.

On Fri, Mar 13, 2009 at 10:51 AM, Mike Klaas <> wrote:

> Anyway, just a note to say that boolean matching is important to me
>> and my users; it'd be good if it worked the way it looks like it
>> would.  If it doesn't, I need to understand better what the current
>> limitations are.
> Well, this is precisely why I am suggesting that we remove it (in some
> future version of Lucene).  Lucene doesn't have a hierarchical boolean query
> model that works like people "expect", and bugs filed that report
> discrepancies between the way boolean operators work and intuition are
> rejected.  We are left with something that is convenient if you understand
> how it works, but if that is so, there is no reason that translation into
> the alternate syntax can't be used.
> Lucene's query model is based on REQUIRED, OPTIONAL, and EXCLUDED clauses.
>  A clause with no annotation is always OPTIONAL, and doesn't affect matching
> unless there are only OPTIONAL clauses on that level.  brackets () create a
> subclause (note that this is OPTIONAL by default!).  AND terms are
> translated into REQUIRED clauses, AND NOT's are translated into EXCLUDED
> clauses.  Require clauses are annotated with +'s

Ted Dunning, CTO

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message