lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Høydahl (Commented) (JIRA) <j...@apache.org>
Subject [jira] [Commented] (SOLR-2649) MM ignored in edismax queries with operators
Date Thu, 02 Feb 2012 21:44:53 GMT

    [ https://issues.apache.org/jira/browse/SOLR-2649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13199259#comment-13199259
] 

Jan Høydahl commented on SOLR-2649:
-----------------------------------

Yes I think the key here is what terms are part of some user imposed operator (forced MUST
or MUST NOT) vs what terms are left dangling in the wild to be subject to mm. But what about
this

{noformat}
q=word1 AND word2 (word3 OR word4) word5%mm=100%
{noformat}
Should this be interpreted as MUST have word1 AND word2 and set mm=3 for word3, word4, word5?
Don't think so. An OR does not mean the same as a "loose" term. This would clearly (perhaps
because of the parens) signal that word3 OR word4 should be treated as one unit, not requiring
both of them?
                
> 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: search
>    Affects Versions: 3.3
>            Reporter: Magnus Bergmark
>            Priority: Minor
>
> 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