[ https://issues.apache.org/jira/browse/SOLR-3741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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