[
https://issues.apache.org/jira/browse/SOLR-11775?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17025968#comment-17025968
]
Jason Gerlowski edited comment on SOLR-11775 at 1/29/20 3:30 PM:
-----------------------------------------------------------------
bq. I'm not opposed to changing the behavior, but I disagree that this is a bug.
Don't really have an opinion on how this is classified.
But can we agree that, purely as a usability improvement, it'd be nice for our
users (internal code included) if the return value was always {{long}} here?
If so, the classification doesn't really matter and someone is good to pursue
this change.
was (Author: gerlowskija):
bq. I'm not opposed to changing the behavior, but I disagree that this is a bug.
Don't really have an opinion on how this is classified.
But can we agree that, purely as a usability improvement, it'd be nice for our
users (internal code included) if the return value was always {{long}} here?
If so, the classification doesn't really matter and we're good to pursue this
change.
> json.facet can use inconsistent Long/Integer for "count" depending on shard
> count
> ---------------------------------------------------------------------------------
>
> Key: SOLR-11775
> URL: https://issues.apache.org/jira/browse/SOLR-11775
> Project: Solr
> Issue Type: Bug
> Components: Facet Module
> Reporter: Chris M. Hostetter
> Priority: Major
>
> (NOTE: I noticed this while working on a test for {{type: range}} but it's
> possible other facet types may be affected as well)
> When dealing with a single core request -- either standalone or a collection
> with only one shard -- json.facet seems to use "Integer" objects to return
> the "count" of facet buckets, however if the shard count is increased then
> the end client gets a "Long" object for the "count"
> (This isn't noticable when using {{wt=json}} but can be very problematic when
> trying to write client code using {{wt=xml}} or SolrJ
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
