[
https://issues.apache.org/jira/browse/SOLR-3739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hoss Man updated SOLR-3739:
---------------------------
Fix Version/s: (was: 4.0)
(was: 3.6.2)
removing fixVersion=4.0 since there is no evidence that anyone is currently
working on this issue. (this can certainly be revisited if volunteers step
forward)
> 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
>
> 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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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]