You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Erick Erickson (JIRA)" <ji...@apache.org> on 2018/04/09 04:39:00 UTC

[jira] [Commented] (SOLR-3739) ExtendedDismaxQParser (edismax) does not obey q.op for tokens split by an analyzer

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