I'm not certain what is going on with your boost. It doesn't seem related
to those tickets as far as I can see, but I note it comes back in the
'parsedquery_toString' step below that. Perhaps the debug output has a
display bug?
The fact that 4.10 was not applying 'mm' in this context relates the other
part of 2649. Because you provided an explicit OR operator inside this
particular search string the 'mm' parameter was ignored. This confusing(?)
behaviour was the primary reason 2649 was originally opened. Under 5.5 it
was applied, so you get the '~2' operator. Because you explicitly set the
'mm' parameter to 100% it required both or your 'should' OCCUR terms to be
present.
Are you setting mm to 100% consciously because you want every term to
always apply, or was it just a leftover setting?
I can see that if you were relying on this behaviour it might appear
disruptive, but what I would hope is that you can see that 5.5 did
everything you asked it to, following clear and consistent rules for your
parameters to influence the output. But 4.10 was following some internal,
rarely/poorly documented behaviours that people had just learned to live
with. Some parameters did nothing, other parameters influenced yet more
parameters in confusing ways. Those old behaviours had various pitfalls
that created use cases edismax could not support so it got cleaned up.
If you want edismax to behave (mostly) the old way, set q.op to 'OR' and
'mm' to whatever you would like. I say 'mostly' because 'mm' will now be
paid attention to if you add your own operators. But if you really, really
want it to ignore that you can always wrap your search in parentheses to
group all the terms into a single clause. 'mm' only applies to top level
clauses and always has.
If you want to use edismax for simpler boolean search logic, set 'q.op' to
whatever you would like and 'mm' to something like 0 or 1 so that is
doesn't screw with your boolean ORs.
Ta,
Greg
Ta,
Greg
On 9 September 2016 at 20:00, Bernd Fehling <bernd.fehl...@uni-bielefeld.de>
wrote:
> After some more testing it feels like the parsing in 5.5.3 is _really_
> messed up.
>
> Query version 4.10.4:
>
> <str name="rawquerystring">
> (text:(star AND trek AND wars)^200 OR text:("star trek wars")^350)
> </str>
> <str name="querystring">
> (text:(star AND trek AND wars)^200 OR text:("star trek wars")^350)
> </str>
> <str name="parsedquery">
> (+(((+text:star +text:trek +text:war)^200.0) PhraseQuery(text:"star trek
> war"^350.0)))/no_coord
> </str>
> <str name="parsedquery_toString">
> +(((+text:star +text:trek +text:war)^200.0) text:"star trek war"^350.0)
> </str>
>
>
> Same query version 5.5.3:
>
> <str name="rawquerystring">
> (text:(star AND trek AND wars)^200 OR text:("star trek wars")^350)
> </str>
> <str name="querystring">
> (text:(star AND trek AND wars)^200 OR text:("star trek wars")^350)
> </str>
> <str name="parsedquery">
> (+((+text:star +text:trek +text:war^200.0 PhraseQuery(text:"star trek
> war"))~2))/no_coord
> </str>
> <str name="parsedquery_toString">
> +(((+text:star +text:trek +text:war)^200.0 text:"star trek war"^350.0)~2)
> </str>
>
> As you can see version 5.5.3 "parsedquery" is different to version 4.10.4.
>
> And why is parsedquery different to parsedquery_toString in version 5.5.3?
>
> Where is my second boost in "parsedquery" of 5.5.3?
>
>
> Bernd
>
>
>
> Am 09.09.2016 um 08:44 schrieb Bernd Fehling:
> > Hi Greg,
> >
> > thanks a lot, thats it.
> > After setting q.op to OR it works _nearly_ as before with 4.10.4.
> >
> > But how stupid this?
> > I have in my schema <solrQueryParser defaultOperator="AND"/>
> > and also had q.op to AND to make sure my default _is_ AND,
> > meant as conjunction between terms.
> > But now I have q.op to OR and defaultOperator in schema to AND
> > to just get _nearly_ my old behavior back.
> >
> > schema has following comment:
> > "... The default is OR, which is generally assumed so it is
> > not a good idea to change it globally here. The "q.op" request
> > parameter takes precedence over this. ..."
> >
> > What I don't understand is why they change some major internals
> > and don't give any notice about how to keep old parsing behavior.
> >
> > From my point of view the old parsing behavior was correct.
> > If searching for a term without operator it is always OR, otherwise
> > you can add "+" or "-" to modify that. Now with q.op AND it is
> > modified to "+" as a MUST.
> >
> > I still get some differences in search results between 4.10.4 and 5.5.3.
> > What other side effects has this change of q.op from AND to OR in
> > other parts of query handling, parsing and searching?
> >
> > Regards
> > Bernd
> >
> > Am 09.09.2016 um 05:43 schrieb Greg Pendlebury:
> >> I forgot to mention the tickets:
> >> SOLR-2649 and SOLR-8812
> >>
> >> On 9 September 2016 at 13:38, Greg Pendlebury <
> greg.pendleb...@gmail.com>
> >> wrote:
> >>
> >>> Under 4.10 q.op was ignored by the edismax parser and always forced to
> OR.
> >>> 5.5 is looking at the q.op=AND you requested.
> >>>
> >>> There are also some changes to the default values selected for mm, but
> I
> >>> doubt those apply here since you are setting it explicitly.
> >>>
> >>> On 8 September 2016 at 00:35, Mikhail Khludnev <m...@apache.org>
> wrote:
> >>>
> >>>> I suppose
> >>>> <str name="parsedquery_toString">+((text:star text:trek)~2)</str>
> >>>> and
> >>>> <str name="parsedquery_toString">+(+text:star +text:trek)</str>
> >>>> are equal. mm=2 is equal to +foo +bar
> >>>>
> >>>> On Wed, Sep 7, 2016 at 10:52 AM, Bernd Fehling <
> >>>> bernd.fehl...@uni-bielefeld.de> wrote:
> >>>>
> >>>>> Hi list,
> >>>>>
> >>>>> while going from SOLR 4.10.4 to 5.5.3 I noticed a change in query
> >>>> parsing.
> >>>>> 4.10.4
> >>>>> <str name="rawquerystring">text:star text:trek</str>
> >>>>> <str name="querystring">text:star text:trek</str>
> >>>>> <str name="parsedquery">(+((text:star
> text:trek)~2))/no_coord</str>
> >>>>> <str name="parsedquery_toString">+((text:star text:trek)~2)</str>
> >>>>>
> >>>>> 5.5.3
> >>>>> <str name="rawquerystring">text:star text:trek</str>
> >>>>> <str name="querystring">text:star text:trek</str>
> >>>>> <str name="parsedquery">(+(+text:star +text:trek))/no_coord</str>
> >>>>> <str name="parsedquery_toString">+(+text:star +text:trek)</str>
> >>>>>
> >>>>> There are very many new features and changes between this two
> versions.
> >>>>> It looks like a change in query parsing.
> >>>>> Can someone point me to the solr or lucene jira about the changes?
> >>>>> Or even give a hint how to get my "old" query parsing back?
> >>>>>
> >>>>> Regards
> >>>>> Bernd
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> Sincerely yours
> >>>> Mikhail Khludnev
> >>>>
>
