[
https://issues.apache.org/jira/browse/SOLR-15031?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17294419#comment-17294419
]
Pieter commented on SOLR-15031:
-------------------------------
[~dsmiley], I agree with that comment, I also thought the real problem is
QParser.parse returning null, but I did not dare to suggest to deal with that.
Since the introduction of the Java language it supports the concept of null
values, which is abused by programmers to give "null" a special meaning. That
happened in Lucene too, QParser.parse is allowed to return null when the input
does not produce a Query. Java 8 finally brought a solution with the Optional
type and I think that would be the ideal solution here too. Changing the return
type of QParser.parse however is a breaking change which is though. Maybe we
can introduce a new QParser.parse method, mark the current one deprecated and
refactor all Lucene&Solr code to use the new?
Alternatively, we can change the contract as you suggest, but that's
problematic too because how do we prevent it from breaking stuff? We can
refactor all Solr and Lucene code, but people (like me) write their own query
parsers and code calling such query parsers. Such code also needs to be
reviewed and how do we enforce that? Even if I have a junit test assuming
QParser.parse to return null and coding that assumption in a mock QParser, that
test will not break after changing the contract. I think the only way to
enforce such change and to make sure it is dealt with, is to make a breaking
change like changing the return type as suggested above.
> NPE caused by FunctionQParser returning a null ValueSource
> ----------------------------------------------------------
>
> Key: SOLR-15031
> URL: https://issues.apache.org/jira/browse/SOLR-15031
> Project: Solr
> Issue Type: Bug
> Reporter: Pieter
> Assignee: Mike Drob
> Priority: Minor
> Fix For: 8.8, master (9.0)
>
> Time Spent: 2h 10m
> Remaining Estimate: 0h
>
> When parsing a sub query in a function query,
> {{FunctionQParser#parseValueSource}} does not check if the produced query
> object is null. When it is, it just wraps a null in a {{QueryValueSource}}
> object. This is a cause for NPE's in code consuming that object. Parsed
> queries can be null, for example when the query string only contains
> stopwords, so we need handle that condition.
> h3. Steps to reproduce the issue
> # Start solr with the techproducts example collection: {{solr start -e
> techproducts}}
> # Add a stopword to
> SOLR_DIR/example/techproducts/solr/techproducts/conf/stopwords.txt, for
> example "at"
> # Reload the core
> # Execute a function query:
> {code:java}
> http://localhost:8983/solr/techproducts/select?fieldquery={!field%20f=features%20v=%27%22at%22%27}&q={!func}%20if($fieldquery,1,0){code}
> The following stacktrace is produced:
> {code:java}
> 2020-12-03 13:35:38.868 INFO (qtp2095677157-21) [ x:techproducts]
> o.a.s.c.S.Request [techproducts] webapp=/solr path=/select
> params={q={!func}+if($fieldquery,1,0)&fieldquery={!field+f%3Dfeatures+v%3D'"at"'}}
> status=500 QTime=34
> 2020-12-03 13:35:38.872 ERROR (qtp2095677157-21) [ x:techproducts]
> o.a.s.s.HttpSolrCall null:java.lang.NullPointerException
> at
> org.apache.lucene.queries.function.valuesource.QueryValueSource.hashCode(QueryValueSource.java:63)
> at
> org.apache.lucene.queries.function.valuesource.IfFunction.hashCode(IfFunction.java:129)
> at
> org.apache.lucene.queries.function.FunctionQuery.hashCode(FunctionQuery.java:176)
> at
> org.apache.solr.search.QueryResultKey.<init>(QueryResultKey.java:53)
> at
> org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:1341)
> at
> org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:580)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
