Hi Bast, Good to know you got it to work - thanks for letting us know!
-- Steve www.lucidworks.com > On Sep 2, 2016, at 4:30 AM, Bastien Latard | MDPI AG > <lat...@mdpi.com.INVALID> wrote: > > Thanks Steve for your advice (i.e.: upgrade to Solr 6.2). > I finally had time to upgrade and can now use "&q.op=AND" together with "&q=a > OR b" and this works as expected. > > I even defined the following line in the defaults settings in the > requestHandler, to overwrite the default behavior: > <str name="q.op">AND</str> > > Issue fixed :) > > Kind regards, > Bast > > On 05/08/2016 14:57, Bastien Latard | MDPI AG wrote: >> Hi Steve, >> >> I read the thread you sent me (SOLR-8812) and it seems that the 6.1 includes >> this fix, as you said. >> I will upgrade. >> Thank you! >> >> Kind regards, >> Bast >> >> On 05/08/2016 14:37, Steve Rowe wrote: >>> Hi Bastien, >>> >>> Have you tried upgrading to 6.1? SOLR-8812, mentioned earlier in the >>> thread, was released with 6.1, and is directly aimed at fixing the problem >>> you are having in 6.0 (also a problem in 5.5): when mm is not explicitly >>> provided and the query contains explicit operators (except for AND), >>> edismax now sets mm=0. >>> >>> -- >>> Steve >>> www.lucidworks.com >>> >>>> On Aug 5, 2016, at 2:34 AM, Bastien Latard | MDPI AG >>>> <lat...@mdpi.com.INVALID> wrote: >>>> >>>> Hi Eric & others, >>>> Is there any way to overwrite the default OP when we use edismax? >>>> Because adding the following line to solrconfig.xml doesn't solve the >>>> problem: >>>> <solrQueryParser defaultOperator="AND"/> >>>> >>>> (Then if I do "q=black OR white", this always gives the results for "black >>>> AND white") >>>> >>>> I did not find a way to define a default OP, which is automatically >>>> overwritten by the AND/OR from a query. >>>> >>>> >>>> Example - Debug: defaultOP in solrconfig = AND / q=a or b >>>> <Mail Attachment.png> >>>> >>>> ==> results for black AND white >>>> The correct result should be the following (but I had to force the q.op): >>>> <Mail Attachment.png> >>>> ==> I cannot do this in case I want to do "(a AND b) OR c"... >>>> >>>> >>>> Kind regards, >>>> Bastien >>>> >>>> On 27/04/2016 05:30, Erick Erickson wrote: >>>>> Defaulting to "OR" has been the behavior since forever, so changing the >>>>> behavior now is just not going to happen. Making it fit a new version of >>>>> "correct" will change the behavior for every application out there that >>>>> has not specified the default behavior. >>>>> >>>>> There's no a-priori reason to expect "more words to equal fewer docs", I >>>>> can just as easily argue that "more words should return more docs". Which >>>>> you expect depends on your mental model. >>>>> >>>>> And providing the default op in your solrconfig.xml request handlers >>>>> allows you to implement whatever model your application chooses... >>>>> >>>>> Best, >>>>> Erick >>>>> >>>>> On Mon, Apr 25, 2016 at 11:32 PM, Bastien Latard - MDPI AG >>>>> <lat...@mdpi.com.invalid> wrote: >>>>> Thank you Shawn, Jan and Georg for your answers. >>>>> >>>>> Yes, it seems that if I simply remove the defaultOperator it works well >>>>> for "composed queries" like '(a:x AND b:y) OR c:z'. >>>>> But I think that the default Operator should/could be the AND. >>>>> >>>>> Because when I add an extra search word, I expect that the results get >>>>> more accurate... >>>>> (It seems to be what google is also doing now) >>>>> | | >>>>> >>>>> Otherwise, if you make a search and apply another filter (e.g.: sort by >>>>> publication date, facets, ...) , user can get the less relevant item >>>>> (only 1 word in 4 matches) in first position only because of its date... >>>>> >>>>> What do you think? >>>>> >>>>> >>>>> Kind regards, >>>>> Bastien >>>>> >>>>> >>>>> On 25/04/2016 14:53, Shawn Heisey wrote: >>>>>> On 4/25/2016 6:39 AM, Bastien Latard - MDPI AG wrote: >>>>>> >>>>>>> Remember: >>>>>>> If I add the following line to the schema.xml, even if I do a search >>>>>>> 'title:"test" OR author:"me"', it will returns documents matching >>>>>>> 'title:"test" AND author:"me"': >>>>>>> <solrQueryParser defaultOperator="AND"/> >>>>>>> >>>>>> The settings in the schema for default field and default operator were >>>>>> deprecated a long time ago. I actually have no idea whether they are >>>>>> even supported in newer Solr versions. >>>>>> >>>>>> The q.op parameter controls the default operator, and the df parameter >>>>>> controls the default field. These can be set in the request handler >>>>>> definition in solrconfig.xml -- usually in "defaults" but there might be >>>>>> reason to put them in "invariants" instead. >>>>>> >>>>>> If you're using edismax, you'd be better off using the mm parameter >>>>>> rather than the q.op parameter. The behavior you have described above >>>>>> sounds like a change in behavior (some call it a bug) introduced in the >>>>>> 5.5 version: >>>>>> >>>>>> >>>>>> https://issues.apache.org/jira/browse/SOLR-8812 >>>>>> >>>>>> >>>>>> If you are using edismax, I suspect that if you set mm=100% instead of >>>>>> q.op=AND (or the schema default operator) that the problem might go away >>>>>> ... but I am not sure. Someone who is more familiar with SOLR-8812 >>>>>> probably should comment. >>>>>> >>>>>> Thanks, >>>>>> Shawn >>>>>> >>>>>> >>>>>>
