[ 
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]

Reply via email to