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
BooleanQuery.
- Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
