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 > > > > > Kind regards, > Bastien Latard > Web engineer > -- > MDPI AG > Postfach, CH-4005 Basel, Switzerland > Office: Klybeckstrasse 64, CH-4057 > Tel. +41 61 683 77 35 > Fax: +41 61 302 89 18 > E-mail: latard@mdpi.comhttp://www.mdpi.com/ > >
