On Sat, 11 Apr 2020, Eran Buchnick wrote: : Date: Sat, 11 Apr 2020 23:34:37 +0300 : From: Eran Buchnick <buchni...@gmail.com> : Reply-To: solr-user@lucene.apache.org : To: solr-user@lucene.apache.org : Subject: Re: Required operator (+) is being ignored when using default : conjunction operator AND : : 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.
Sure, And i appreciate you asking up about this -- it spurred me to file this... https://issues.apache.org/jira/browse/LUCENE-9315 : 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/ : > : -Hoss http://www.lucidworks.com/
