[
https://issues.apache.org/jira/browse/SOLR-2649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13436088#comment-13436088
]
Jack Krupansky commented on SOLR-2649:
--------------------------------------
I just ran a test with 4.0-BETA and it turns out that overriding the default
operator (using the "q.op" parameter) is also ignored when any operator is
present, for the exact same reason that "mm" is ignored - since edismax
implements q.op using minMatch, which is disabled by the presence of an
operator. As commented above, that aspect of the problem has been around for a
year now. Wow.
I'm leaning towards relaxing the "mm" rules so that minMatch will occur
regardless of whether operators are present. But, I think the default for "mm"
should be "0%", rather than based on "q.op" as is done today.
I suspect that the restriction on use of minMatch may have been a side effect
of having "mm" default based on "q.op". For example, if the user query is "x y
+z", they are explicitly detailing which terms should be ANDed, so it wouldn't
make sense in that case to apply q.op to x and y, but it still makes sense to
apply minMatch to all optional terms. But if no operators are present, THEN you
want q.op to apply to each term, and minMatch as well.
In short, q.op should only apply when no operators are present, but minMatch
should apply when either q.op=OR or there are optional terms present.
I still need to think about the interaction between edismax and the Lucene
query parser, especially for nested queries, such as (a b c) AND (d e
+f)&q.op=AND. Currently, the minMatch processing in edismax is limited to the
top-level BooleanQuery, not any nested queries.
> MM ignored in edismax queries with operators
> --------------------------------------------
>
> Key: SOLR-2649
> URL: https://issues.apache.org/jira/browse/SOLR-2649
> Project: Solr
> Issue Type: Bug
> Components: query parsers
> Reporter: Magnus Bergmark
> Priority: Minor
> Fix For: 4.0
>
>
> Hypothetical scenario:
> 1. User searches for "stocks oil gold" with MM set to "50%"
> 2. User adds "-stockings" to the query: "stocks oil gold -stockings"
> 3. User gets no hits since MM was ignored and all terms where AND-ed
> together
> The behavior seems to be intentional, although the reason why is never
> explained:
> // For correct lucene queries, turn off mm processing if there
> // were explicit operators (except for AND).
> boolean doMinMatched = (numOR + numNOT + numPluses + numMinuses) == 0;
> (lines 232-234 taken from
> tags/lucene_solr_3_3/solr/src/java/org/apache/solr/search/ExtendedDismaxQParserPlugin.java)
> This makes edismax unsuitable as an replacement to dismax; mm is one of the
> primary features of dismax.
--
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: [email protected]
For additional commands, e-mail: [email protected]
