[
https://issues.apache.org/jira/browse/SOLR-3085?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14173329#comment-14173329
]
David Smiley commented on SOLR-3085:
------------------------------------
I like the "convert to boost query" approach. I independently arrived at that
solution, though I haven't put it into practice. The all-stop-words case (e.g.
"who is the who" or "to be or not to be") could be special-cased to not convert
these clauses to boost queries. Granted it seems unlikely in this example
you'd find anything since the 'qf' field you point to that is analyzed
differently (e.g. string field) would need all of them. But if you configure
stop words then this is expected behavior -- it's the conscious trade-off you
make by filtering them. Another possibility is OR'ing in the query as a
phrase, giving an opportunity for common-grams/shingling to find matches.
> Fix the dismax/edismax stopwords mm issue
> -----------------------------------------
>
> Key: SOLR-3085
> URL: https://issues.apache.org/jira/browse/SOLR-3085
> Project: Solr
> Issue Type: Bug
> Components: query parsers
> Reporter: Jan Høydahl
> Labels: MinimumShouldMatch, dismax, edismax, stopwords
> Fix For: Trunk
>
> Attachments: SOLR-3085.patch, SOLR-3085.patch, SOLR-3085.patch
>
>
> As discussed here http://search-lucene.com/m/Wr7iz1a95jx and here
> http://search-lucene.com/m/Yne042qEyCq1 and here
> http://search-lucene.com/m/RfAp82nSsla DisMax has an issue with stopwords if
> not all fields used in QF have exactly same stopword lists.
> Typical solution is to not use stopwords or harmonize stopword lists across
> all fields in your QF, or relax the MM to a lower percentag. Sometimes these
> are not acceptable workarounds, and we should find a better solution.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
