You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "ASF subversion and git services (JIRA)" <ji...@apache.org> on 2017/03/03 13:18:46 UTC
[jira] [Commented] (SOLR-10155) Clarify logic for term filters on
numeric types
[ https://issues.apache.org/jira/browse/SOLR-10155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15894323#comment-15894323 ]
ASF subversion and git services commented on SOLR-10155:
--------------------------------------------------------
Commit 43474312eb2b66df4102bd653b9546e7eff47363 in lucene-solr's branch refs/heads/master from [~cpoerschke]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=4347431 ]
SOLR-10155: For numeric types facet.contains= and facet.prefix= are now rejected.
(Gus Heck, Christine Poerschke)
> Clarify logic for term filters on numeric types
> -----------------------------------------------
>
> Key: SOLR-10155
> URL: https://issues.apache.org/jira/browse/SOLR-10155
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: faceting
> Affects Versions: 6.4.1
> Reporter: Gus Heck
> Assignee: Christine Poerschke
> Priority: Minor
> Attachments: SOLR-10155.patch, SOLR-10155.patch
>
>
> The following code has been found to be confusing to multiple folks working in SimpleFacets.java (see SOLR-10132)
> {code}
> if (termFilter != null) {
> // TODO: understand this logic... what is the case for supporting an empty string
> // for contains on numeric facets? What does that achieve?
> // The exception message is misleading in the case of an excludeTerms filter in any case...
> // Also maybe vulnerable to NPE on isEmpty test?
> final boolean supportedOperation = (termFilter instanceof SubstringBytesRefFilter) && ((SubstringBytesRefFilter) termFilter).substring().isEmpty();
> if (!supportedOperation) {
> throw new SolrException(ErrorCode.BAD_REQUEST, FacetParams.FACET_CONTAINS + " is not supported on numeric types");
> }
> }
> {code}
> This is found around line 482 or so. The comment in the code above is mine, and won't be found in the codebase. This ticket can be resolved by eliminating the complex check and just denying all termFilters with a better exception message not specific to contains filters (and perhaps consolidated with the proceeding check for about prefix filters?), or adding a comment to the code base explaining why we need to allow a term filter with an empty, non-null string to be processed, and why this isn't an NPE waiting to happen.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org