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