Yeah, semi-sort-of a known issue. Basically, the “mm” parameter is ignored below the top-level of the query (i.e., within parentheses, except for some special cases.)
Here’s another example where the implicit “AND” operator gets ignored: http://localhost:8983/solr/collection1/browse?defType=edismax&q=(Thomas+Michael)+(Thomas+Michael) That does an “AND” of the two identical parenthesized queries, which should give the same results, but suddenly the two terms within parentheses become OR/Should, as you saw. The reason your first query in parentheses works is because although it is parenthesized syntactically, semantically it generates a single Lucene BooleanQuery, and that is where the “mm”/q.op is applied. But once you add another term outside the parentheses, the parenthesized query drops down to being a second level of Lucene Boolean Query and now the application of “mm” is still to the top level, not that second level where Thomas and Michael are hanging out. What is really happening is that the q.op, “AND” is NOT passed down to the Lucene Query Parser, and instead the effect of the implied OR operator is accomplished by adding the “minMatch” to the top-level BooleanQuery. -- Jack Krupansky From: Burgmans, Tom Sent: Wednesday, December 12, 2012 7:51 AM To: solr-user@lucene.apache.org Subject: edismax: implicit AND changes into implicit OR Hi all, I wonder if this is a bug or expected behavior: I have some documents indexed; 3 of them contain “Thomas” and 4 of them contain “Michael”, but none of the contain both. A search for http://localhost:8983/solr/collection1/browse?defType=edismax&q=(Thomas+Michael) returns 0 results as expected since there is an implicit AND between the two terms and there is no document that matches both. But a search for http://localhost:8983/solr/collection1/browse?defType=edismax&q=(Thomas+Michael)+OR+xxxmatchesnothingxxx returns 7 results. For some reason the implicit AND turns into an implicit OR, in case an Explicit OR is added to the query expression. The parsedquery information confirms this behavior. Why is edismax doing this? Tested on a Solr 4.0.0 instance. Thanks, Tom -- Tom Burgmans Search Specialist Tel: +31 (0)17 246 66 33 Mobile: +31 (0)6 306 821 78 Platform Technologies Global Platform Organization Zuidpoolsingel 2 2408 ZE, Alphen aan den Rijn The Netherlands tom.burgm...@wolterskluwer.com www.wolterskluwer.com -------------------------------------------------------------------------------- This email and any attachments may contain confidential or privileged information and is intended for the addressee only. If you are not the intended recipient, please immediately notify us by email or telephone and delete the original email and attachments without using, disseminating or reproducing its contents to anyone other than the intended recipient. Wolters Kluwer shall not be liable for the incorrect or incomplete transmission of of this email or any attachments, nor for unauthorized use by its employees. Wolters Kluwer nv has its registered address in Alphen aan den Rijn, The Netherlands, and is registered with the Trade Registry of the Dutch Chamber of Commerce under number 33202517.
