lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hoss Man (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (SOLR-3739) ExtendedDismaxQParser (edismax) does not obey q.op for tokens split by an analyzer
Date Sat, 08 Sep 2012 00:37:08 GMT

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


Mime
View raw message