lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jack Krupansky (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (SOLR-3741) ExtendedDismaxQParser (edismax) does not obey q.op for queries with operators
Date Sun, 19 Aug 2012 14:14:37 GMT

    [ 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message