Hoss, thanks a lot for the informative response. I understood my
misunderstanding with infix and prefix operators. Need to rethink about the
term occurrence support in my search service.
Cheers!
On Mon, Apr 6, 2020, 20:43 Chris Hostetter <hossman_luc...@fucit.org> wrote:
>
> : 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/
>
