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-2649) MM ignored in edismax queries with operators
Date Thu, 16 Aug 2012 16:49:38 GMT

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


Mime
View raw message