Hi Greg, after trying several hours with all combinations of parameters and not getting any useful search result with complex search terms and edismax I finally copied o.a.s.s.ExtendedDismaxQParser.java from version 4.10.4 to 5.5.3 and did a little modification in o.a.s.u.SolrPluginUtils.java.
Now it is searching correct and getting logical and valid search results with any kind of complex search. Problem solved. But still, the edismax, at least of 5.5.3, has some bugs. If I get time I will look into this but right now my problem is solved and the customers and users are happy. I hope that this buggy edismax version is not used in solr 6.x otherwise you have the same problems there. Regards Bernd Am 12.09.2016 um 05:10 schrieb Greg Pendlebury: > 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 >>>>> >> >
