lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Miller <>
Subject Re: Technology Preview of new Lucene QueryParser
Date Sun, 21 Jan 2007 03:09:42 GMT

Chris Hostetter wrote:
> : This exchange has caused me to reassess my syntax. It seems that
> : QueryParser's handling of A B C -D -E is special because QueryParser
> : does not have any operator precedence rules (unless the 1 rule is that
> : all operators resolve with the same precedence <g>). What would appear
> there are some precedence rules, but they really only apply when using
> "AND", "OR", or "NOT" -- which as i've gone on record with many teams: are
> big freaking hasks that people shouldn't use.
 From what I understand "AND", "OR", and "NOT" do not follow normal 
precedence rules. I thought instead that AND just means to MUST both 
sides of the AND and OR means to SHOULD both sides etc. While this might 
create a form of precedence, it's a confusing oddity that I am not a fan 
of either. I am sure I saw a comment from Erick explaining that the 
QueryParser to works this way.

With my syntax you can get real precedence that mixes with how no 
precedence (Lucene's unary operators) works. No precedence is created by 
allowing you to make any operator resolve first...any operator that 
resolves first connected with another operator that resolves first will 
behave as if neither has precedence over the other and generate a single 

- Mark

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

View raw message