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 >>>
