: I red your attached blog post (and more) but still the penny hasn't dropped
: yet about what causes the operator clash when the default operator is AND.
: I red that when q.op=AND, OR will change the left(if not MUST_NOT) and
: right clause Occurs to SHOULD - what that means is that the "order of
: operations" in this case is giving the infix operator the mandate to
: control the prefix operator?
Not quite anything that complex... sorry, but the blog post was focused on
describe *what* happens when parsing, do explain why mixng prefix/infix is
bad ... i avoided getting bogged down into *why* it happens exactly the
way it does.
To get to the "why" you have to circle back to the higher level concept
that the "prefix" operators very closely align to the underlying concepts
of the BooleanQuery/BooleanClause data structures: that each clause has an
"Occur" property which is either: MUST/SHOULD/MUST_NOT (or FILTER, but
setting asside scoring that's functionally equivilent to MUST).
The 'infix' operators just manipulate the Occur property of the clauses on
either side of them.
'q.op=AND' and 'q.op=OR' are functionally really about setting the
"Default Occur Value For All Clauses That Do Not Have An Explicit Occur
Value" (ie: q.op=Occur.MUST and q.op=Occur.SHOULD) ... where the explicit
Occur value for each clause would be specified by it's prefix (+=MUST,
-=MUST_NOT ... there is no supported prefix for SHOULD, which is why
q.op=SHOULD is the defualt nad chaning it complicates the parser logic)
In essence: After the q.op/default.occur is applied to all clauses (that
don't already have a prefix), then there is a left to right parsing that
let's the infix operators modify the "Occur" values of the clauses on
either side of them -- if those Occur values match the "default" for this
parser.
So let's imagine 2 requests...
1) {!q.op=AND}a +b OR c +d AND e
2) {!q.op=OR} x +y OR z +r AND s
Here's what those wind up looking like internally with the default
applied...
1) q.op=MUST: MUST(a) MUST(b) OR MUST(c) MUST(d) AND MUST(e)
2) q.op=SHOULD: SHOULD(x) MUST(y) OR SHOULD(z) MUST(r) AND SHOULD(s)
And here's how the infix operators change things as it parses left to
right building up the clauses...
1) q.op=MUST: MUST(a) SHOULD(b) SHOULD(c) MUST(d) MUST(e)
2) q.op=SHOULD: SHOULD(x) MUST(y) SHOULD(z) MUST(r) MUST(s)
It's not actually done in "two passes" -- it's just that as the parsing
is done left to right, the default Occur is used unless/until set by a
prefix operators, and infix operators not only set the occur value
for the "next" clause, but also reach back to override the prior
Occur value if it matches the Default: because there is no "history" kept
to indicate that it was explicitly set, or how. the left to right parsing
just does the best it can with the context it's got.
: A little background - I am trying to implement a google search like
: service and want to have the ability to have required and prohibit
: operators while still allowing default intersection operation as default
: operator. How can I achieve this with this limitation?
If you want "intersection" to be the defualt, i'm not sure why you care
about having a "required" operator? (you didn't mention anything about an
"optional" operator even though your original example explicitly used
"OR" ... so not really sure if that was just a contrived example or if you
actaully care about supporting it?
If you're not hung up on using a specific syntax, you might want to
consider the "simple" QParser -- it unfortunately re-uses the 'q.op=AND'
param syntax to indicate what the default Occur should be for clauses, but
the overall syntax is much simple: there is a prefix negation operator,
but other wise the infix "+" and "|" operators support boolean AND and OR
-- there is no prefix operators for MUST/SHOULD. You can also turn off
individual operators you don't like...
https://lucene.apache.org/solr/guide/8_5/other-parsers.html#OtherParsers-SimpleQueryParser
-Hoss
http://www.lucidworks.com/
