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