Hi Bernd, "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."
It is correct in both cases. q.op dictates (for that query) what default operator to use when none is provided, and it is used as a priority over the system whole 'defaultOperator'. In either case, if you ask it to use OR, it uses it; if you ask it to use AND, it uses it. The behaviour from 4.10 that was changed (arguably fixed, although I know that is a debatable point) was that you asked it to use AND, and it ignored you (irrespective of whether you used defaultOperator or q.op). The are a few subtle distinctions that are being missed (like the difference between the boolean operators and the OCCURS flags that your are talking about), but they are not going to change the outcome. 8812 related to users who had been historically setting the q.op parameter to influence the downstream default selection of 'mm' (If you don't provide 'mm' it is set for you based on 'q.op') instead of directly setting the 'mm' value themselves. But again in this case, you're setting 'mm' anyway, so it shouldn't be relevant. Ta, Greg On 9 September 2016 at 16:44, Bernd Fehling <bernd.fehl...@uni-bielefeld.de> wrote: > 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 > >>> >
