[
https://issues.apache.org/jira/browse/SOLR-13318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16833710#comment-16833710
]
Jason Gerlowski commented on SOLR-13318:
----------------------------------------
bq. Would this be okay from a user's perspective?
I agree it's not great, but hopefully its good enough. The approach that I
took here causes anyone currently using BucketBasedJsonFacet to potentially
update their code twice. That's not ideal. You're right. But I also didn't
want new users coming in to 9.0 to see method names that were inconsistent with
the rest of that group of classes (e.g. "What does that "count" suffix mean on
{{getNumBucketsCount}}? Nothing else has that, maybe it doesn't mean what I
think"). Both options are non-ideal, but we have to choose one.
I tried to choose the option that would affect the fewest users. As of 7.x and
8.0, BucketBasedJsonFacet throws an undeclared exception when used with any
multi-shard collection. This is a huge problem, and makes the methods arguably
unusable. Because of this, there are probably very few BBJF users. So I opted
to cause those few users a bit of extra work, in favor of having a more
consistent interface for the users coming on in 9.x, now that the class is
safer.
So anyway, there are negative aspects of this approach, but hopefully
outweighed or mitigated by other things.
> JsonFacetingResponse classes should record provide access to count fields as
> longs
> -----------------------------------------------------------------------------------
>
> Key: SOLR-13318
> URL: https://issues.apache.org/jira/browse/SOLR-13318
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrJ
> Affects Versions: 7.7.1
> Reporter: Jason Gerlowski
> Assignee: Jason Gerlowski
> Priority: Minor
> Attachments: SOLR-13318-branch_8x.patch, SOLR-13318.patch,
> SOLR-13318.patch
>
>
> JsonFacetingResponse and its series of dependent classes hold a variety of
> count fields for bucket counts and various optional properties
> ({{allBuckets}}, {{numBuckets}}, etc.). Currently, some of the code that
> parses these values out of the originating NamedList either stores or casts
> the values as ints. When doc counts are low this works fine. But when the
> doc counts become larger and stray into "long" territory, SolrJ is liable to
> blow up with ClassCastExceptions.
> A user on the list reported on of these with the partial stack trace:
> {code}
> Caused by: java.lang.ClassCastException: java.lang.Long cannot be cast to
> java.lang.Integer
> at
> org.apache.solr.client.solrj.response.json.NestableJsonFacet.<init>(NestableJsonFacet.java:52)
> at
> org.apache.solr.client.solrj.response.QueryResponse.extractJsonFacetingInfo(QueryResponse.java:200)
> at
> org.apache.solr.client.solrj.response.QueryResponse.getJsonFacetingResponse(QueryResponse.java:571)
> {code}
> We should fix this so that these classes can be used without incident for any
> doc counts.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
