[
https://issues.apache.org/jira/browse/LUCENE-7472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steve Rowe resolved LUCENE-7472.
--------------------------------
Resolution: Fixed
Assignee: Steve Rowe
Fix Version/s: 6.2.2
6.3
master (7.0)
Pushed to master, branch_6x and branch_6_2, with slightly different testing on
master versus the other two branches, since the default split-on-whitespace
query parser option, which affects multi-term synonyms used in the added test,
will change on master/7.0.
On java-user mailing list, Oliver Kaleske reported:
{quote}
I locally applied the patch on branch_6_2 (because that is closest to my
current 6.2.1 dependency) and built Lucene from there.
Using the outcome in my application, the problem observed there is fixed.
{quote}
> MultiFieldQueryParser.getFieldQuery() drops queries that are neither
> BooleanQuery nor TermQuery
> ------------------------------------------------------------------------------------------------
>
> Key: LUCENE-7472
> URL: https://issues.apache.org/jira/browse/LUCENE-7472
> Project: Lucene - Core
> Issue Type: Bug
> Reporter: Steve Rowe
> Assignee: Steve Rowe
> Fix For: master (7.0), 6.3, 6.2.2
>
> Attachments: LUCENE-7472.patch
>
>
> From
> [http://mail-archives.apache.org/mod_mbox/lucene-java-user/201609.mbox/%[email protected]%3e],
> Oliver Kaleske reports:
> {quote}
> Hi,
> in updating Lucene from 6.1.0 to 6.2.0 I came across the following:
> We have a subclass of MultiFieldQueryParser (MFQP) for creating a custom type
> of Query, which calls getFieldQuery() on its base class (MFQP).
> For each of its search fields, this method has a Query created by calling
> getFieldQuery() on QueryParserBase.
> Ultimately, we wind up in QueryBuilder's createFieldQuery() method, which
> depending on the number of tokens (etc.) decides what type of Query to
> return: a TermQuery, BooleanQuery, PhraseQuery, or MultiPhraseQuery.
> Back in MFQP.getFieldQuery(), a variable maxTerms is determined depending on
> the type of Query returned: for a TermQuery or a BooleanQuery, its value will
> in general be nonzero, clauses are created, and a non-null Query is returned.
> However, other Query subclasses result in maxTerms=0, an empty list of
> clauses, and finally null is returned.
> To me, this seems like a bug, but I might as well be missing something. The
> comment "// happens for stopwords" on the return null statement, however,
> seems to suggest that Query types other than TermQuery and BooleanQuery were
> not considered properly here.
> I should point out that our custom MFQP subclass so far does some rather
> unsophisticated tokenization before calling getFieldQuery() on each token, so
> characters like '*' may still slip through. So perhaps with proper
> tokenization, it is guaranteed that only TermQuery and BooleanQuery can come
> out of the chain of getFieldQuery() calls, and not handling
> (Multi)PhraseQuery in MFQP.getFieldQuery() can never cause trouble?
> The code in MFQP.getFieldQuery dates back to
> LUCENE-2605: Add classic QueryParser option setSplitOnWhitespace() to control
> whether to split on whitespace prior to text analysis. Default behavior
> remains unchanged: split-on-whitespace=true.
> (06 Jul 2016), when it was substantially expanded.
> Best regards,
> Oliver
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
