[
https://issues.apache.org/jira/browse/SOLR-3739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16430020#comment-16430020
]
Erick Erickson commented on SOLR-3739:
--------------------------------------
Can this be closed? There's been a lot of changes since this was opened.
> ExtendedDismaxQParser (edismax) does not obey q.op for tokens split by an
> analyzer
> ----------------------------------------------------------------------------------
>
> Key: SOLR-3739
> URL: https://issues.apache.org/jira/browse/SOLR-3739
> Project: Solr
> Issue Type: Bug
> Components: query parsers
> Affects Versions: 3.6.1, 4.0-BETA
> Reporter: Jack Krupansky
> Priority: Major
>
> If a field type analyzer splits a query token into multiple terms when the
> classic Lucene query parser is called from the edismax query parser, the
> terms will always be combined with the "OR" operator even if the user has
> explicitly set the default query operator to "AND" with the "q.op" request
> parameter.
> This is because edismax only simulates the default operator by forcing "mm"
> (minMatch) to 100% for the top-level BooleanQuery alone and never sets the
> default query operator when it invokes the classic Lucene Query parser which
> in turn is performing the term analysis and generation of the nested Boolean
> Query for the sub-terms.
> 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.
> Whether to also set the Lucene default query operator to AND when mm=100% is
> another possibility, but subject to debate. It is asserted that mm=100% is
> only supposed to apply to the top-level query and not to any nested
> (parenthesized or split term) queries, but I suggest that failing to treat
> mm=100% as if q.op=AND will lead to more confusion and surprise for
> non-expert users than doing so. Note that there is no current API for setting
> the default minMatch for the classic Lucene query parser, and even if there
> were, the question of whether it should only apply to the top-level query
> would still arise.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
