[
https://issues.apache.org/jira/browse/SOLR-434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12554928
]
Ryan McKinley commented on SOLR-434:
------------------------------------
>
>> I think we can safely change all integers to long without problem.
>
> So you mean, when SolrJ encounters a <int>100</int> it will create a new
> Long(100)?
Yes, thats what I'm suggesting. Likewise when it hits numFound=X and start=Y,
it would also store a long.
> That wouldn't really be backward compatible with SolrJ users, but we haven't
> had a SolrJ release yet.
>
Since their has not been a release, I think that is a reasonable change. For
most use, the only thing people may see is a compiler warning for
int count = results.getNumFound();
>> I don't think the external api <int> makes an contract to say the value will
>> fit within the java int range.
>
> The only issue is that there is a <long> tag...
> I don't think Solr currently uses Long objects for serialization, but long
> field types currently use the <long> tag.
>
good point -- if you have <int> and <long> one would think they mean something
different... also for NamedList configuration (NamedListInitalizedPlugin),
<int> really expects to be a java int field.
> interfaces should support >2B docs
> ----------------------------------
>
> Key: SOLR-434
> URL: https://issues.apache.org/jira/browse/SOLR-434
> Project: Solr
> Issue Type: Improvement
> Reporter: Yonik Seeley
> Priority: Minor
> Fix For: 1.3
>
>
> External interfaces that deal with numbers of documents should eventually be
> able to deal with > 2B documents (that means long instead of int).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
