Perhaps https://issues.apache.org/jira/browse/SOLR-8812 and related?
Best, Erick On Tue, Sep 13, 2016 at 11:37 PM, Bernd Fehling <bernd.fehl...@uni-bielefeld.de> wrote: > 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 >>>>>> >>> >>
