lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eran Buchnick <buchni...@gmail.com>
Subject Re: Required operator (+) is being ignored when using default conjunction operator AND
Date Sun, 05 Apr 2020 18:38:59 GMT
Hoss, thanks a lot for the response.
OK, so it seems like I got into to the "uncanny valley" of the search
operators:/
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?
 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?


On Wed, Apr 1, 2020, 20:08 Chris Hostetter <hossman_lucene@fucit.org> wrote:

>
> : Using solr 8.3.0 it seems like required operator isn't functioning
> properly
> : when default conjunction operator is AND.
>
> You're mixing the "prefix operators" with the "infix operators" which is
> always a recipe for disaster.




>
> The use of q.op=AND vs q.op=OR in these examples only
> complicates the issue because q.op isn't really overriding any sort of
> implicit
> "infix operator" when clauses exist w/o an infix operator between them, it
> is overriding the implicit MUST/SHOULD/MUST_NOT given to each clause as
> parsed ... but in general setting q.op-AND really only makes sense when
> you expect/intend to only be using "infix operators"
>
> This write up i did several years ago is still very accurate -- the bottom
> line is you REALLY don't want to mix infix and prefix operators..
>
>         https://lucidworks.com/post/why-not-and-or-and-not/
>
> ...because the results of mixing them really only "make sense" given the
> context that the parser goes left to right (ie: no precedence) and has
> no explicit "prefix" operator syntax for "SHOULD"
>
>
> -Hoss
> http://www.lucidworks.com/
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message