If you add debugQuery=true to your search you will see how it is parsed: 1. <str name="parsedquery_toString">+(text:medical)</str> 2. <str name="parsedquery_toString">+(((text:medical) (text:retired))~2)</str> 3. <str name="parsedquery_toString">+((text:medical) (text:retired) -(text:working))</str> 4. <str name="parsedquery_toString">+(+(text:medical) +(text:retired) -(text:working))</str>
I think you're seeing an effect of https://issues.apache.org/jira/browse/SOLR-2649 here. Compare the results of 3) with the result when you put -working as a filter instead: <str name="parsedquery_toString">+(((text:medical) (text:retired))~2)</str> <arr name="filter_queries"><str>-working</str></arr> -- Jan Høydahl, search solution architect Cominvent AS - www.cominvent.com Solr Training - www.solrtraining.com 26. feb. 2013 kl. 18:17 skrev z...@navigo.com: > We want to treat all optional parameters as required. I thought setting: > q.op=AND and mm=100% (using edismax request handler) would achieve this > result, but I get unexpected results > > 1) medical => 4,425 > 2) medical retired => 272 > 3) medical retired -working => 5,041 > 4) medical AND retired AND -working => 216 > > We expect the 3rd and 4th queries to be equivalent, but we're obviously > missing something. > > It doesn't seem to be an issue with the number of terms, since: > > medical retired husband => 52 > > Regards, > Z > > > > -- > View this message in context: > http://lucene.472066.n3.nabble.com/Unexpected-Results-tp4043107.html > Sent from the Solr - User mailing list archive at Nabble.com.
