[ https://issues.apache.org/jira/browse/LUCENE-7472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15546561#comment-15546561 ]
ASF subversion and git services commented on LUCENE-7472: --------------------------------------------------------- Commit 64ed2b6492f9d9218ab26550127c5c206f3e25b1 in lucene-solr's branch refs/heads/branch_6_2 from [~steve_rowe] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=64ed2b6 ] LUCENE-7472: remove unused import > 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/%3c944985a6ac27425681bd27abe9d90...@ska-wn-e132.ptvag.ptv.de%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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org