[
https://issues.apache.org/jira/browse/SOLR-3741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13437514#comment-13437514
]
Jack Krupansky commented on SOLR-3741:
--
There is in fact a use case where q.op should be ignored, specifically when the
+ operator is present at the top-level query. In that case, the user is
clearly indicating that they want AND/MUST for one or more terms and it is
easy to see that the user appears to believe that terms without an operator are
not to be treated the same as terms with the explicit +. So, terms without an
explicit operator should implicitly be treated as OR/SHOULD.
One could suggest that the presence of the - operator should invoke the same
treatment, but I assert that: 1) there is nothing about the use of a negative
term that has implications about any preference for the alternatives for
positive terms, and 2) it is too easy for a user to take a working query
without operators and simply add one or more negative terms to try to constrain
the query without intending to otherwise change the semantics of the query.
So, the rule(s) I propose are:
1. If one or more explicit + operators are present at the top-level query,
then OR/SHOULD becomes the default operator, overriding q.op and the normal
default operator given in the code and the request handler.
2. If no explicit + operator is present at the top-level query, q.op is used
as the default operator.
3. q.op will be passed to the classic Lucene query parser for parsing nested
and sub-queries and handling of split terms.
4. MinMatch (mm) should be applied if either an explicit + operator is
present or q.op is OR or is q.op is not present and the code default for q.op
is OR.
ExtendedDismaxQParser (edismax) does not obey q.op for queries with operators
-
Key: SOLR-3741
URL: https://issues.apache.org/jira/browse/SOLR-3741
Project: Solr
Issue Type: Bug
Components: query parsers
Affects Versions: 3.6.1, 4.0-BETA
Reporter: Jack Krupansky
Fix For: 4.0, 3.6.2
For a query such as cat dog OR (fox bat fish) with q.op=AND, the default
query operator remains OR for the entire query. This is not documented
behavior and rather surprising.
This happens because edismax only simulates the default operator by forcing
mm (minMatch) to 100% for the top-level BooleanQuery alone, but only if
there are NO explicit operators present.
One solution is for edismax to always set the default query operator when
calling the classic Lucene query parser, or at least when q.op=AND.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
