<!-- 
RSS generated by JIRA (9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66) at Wed Feb 07 21:36:17 UTC 2024

It is possible to restrict the fields that are returned in this document by specifying the 'field' parameter in your request.
For example, to request only the issue key and summary append 'field=key&field=summary' to the URL of your request.
-->
<rss version="0.92" >
<channel>
    <title>MongoDB Jira</title>
    <link>https://jira.mongodb.org</link>
    <description>This file is an XML representation of an issue</description>
    <language>en-us</language>    <build-info>
        <version>9.7.1</version>
        <build-number>970001</build-number>
        <build-date>13-04-2023</build-date>
    </build-info>


<item>
            <title>[CSHARP-254] Counting documents - 32 bits enough?</title>
                <link>https://jira.mongodb.org/browse/CSHARP-254</link>
                <project id="10041" key="CSHARP">C# Driver</project>
                    <description>&lt;p&gt;I noticed that MongoCollection.Count(...) returns an Int32, while I do not recall MongoDB having a limit of 2^31 documents per collection (this might be the case, I wasn&apos;t trying to remember for too long).&lt;br/&gt;
I wonder if such aggregation methods should return an Int64 to prevent loss (or even misinterpretation) of information on very large collections. While I agree that most of users should not occur this problem, it still looks like worth looking at.&lt;br/&gt;
I took some time and checked Java driver (IIRC the only other one strongly-typed with collection abstraction), it uses &quot;long&quot; type (&lt;a href=&quot;http://api.mongodb.org/java/current/com/mongodb/DBCollection.html#count(&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;http://api.mongodb.org/java/current/com/mongodb/DBCollection.html#count(&lt;/a&gt;) ), which (my Java knowledge is outdated by like 5 years or so, but google comes to help: &lt;a href=&quot;http://download.oracle.com/javase/tutorial/java/nutsandbolts/datatypes.html&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;http://download.oracle.com/javase/tutorial/java/nutsandbolts/datatypes.html&lt;/a&gt;) is 64-bit.&lt;/p&gt;

&lt;p&gt;I understand that changing return type of something like Count() might break existing code (an explicit conversion is required), so this might be not so easy. If the need for 64-bit result is considered by you, but you don&apos;t like the idea of breaking existing code, introducing Count64() (concrete name isn&apos;t that important) counterparts to the existing aggregation methods might be the best way to go in the short term, eventually deprecating old 32-bit results and replacing them with Count32(), moving Count64() to Count().&lt;/p&gt;</description>
                <environment></environment>
        <key id="18573">CSHARP-254</key>
            <summary>Counting documents - 32 bits enough?</summary>
                <type id="3" iconUrl="https://jira.mongodb.org/secure/viewavatar?size=xsmall&amp;avatarId=14718&amp;avatarType=issuetype">Task</type>
                                            <priority id="4" iconUrl="https://jira.mongodb.org/images/icons/priorities/minor.svg">Minor - P4</priority>
                        <status id="6" iconUrl="https://jira.mongodb.org/images/icons/statuses/closed.png" description="The issue is considered finished, the resolution is correct. Issues which are closed can be reopened.">Closed</status>
                    <statusCategory id="3" key="done" colorName="success"/>
                                    <resolution id="9">Done</resolution>
                                        <assignee username="robert@mongodb.com">Robert Stam</assignee>
                                    <reporter username="onyxmaster">Aristarkh Zagorodnikov</reporter>
                        <labels>
                            <label>question</label>
                    </labels>
                <created>Wed, 22 Jun 2011 15:02:51 +0000</created>
                <updated>Fri, 5 Apr 2019 13:58:04 +0000</updated>
                            <resolved>Fri, 22 Jul 2011 14:08:31 +0000</resolved>
                                    <version>1.1</version>
                                    <fixVersion>1.2</fixVersion>
                                                        <votes>0</votes>
                                    <watches>0</watches>
                                                                                                                <comments>
                            <comment id="44007" author="rstam" created="Fri, 22 Jul 2011 14:08:21 +0000"  >&lt;p&gt;I have changed the return values of most of the above items from Int32 to Int64.&lt;/p&gt;

&lt;p&gt;The only exception: I left the types of GeoNearResult as Int32 as on closer examination I don&apos;t believe they can overflow Int32. Reasonsing: ObjectsLoaded must be a relatively small number because all results must be returned in a single document so the number of hits is limited by the document size. NumberScanned is either equal to ObjectsLoaded or some small multiple of it (it would be larger if we have additional filter criteria or if the grid is too coarse). BTreeLocations must be less than or equal to NumberScanned.&lt;/p&gt;
</comment>
                            <comment id="41471" author="rstam" created="Sat, 9 Jul 2011 13:35:07 +0000"  >&lt;p&gt;Thanks for your comment. After reading it, I agree with you. If there is any possibility at all that the result value will ever exceed the range of Int32 then the type of that result should be Int64.&lt;/p&gt;</comment>
                            <comment id="41464" author="onyxmaster" created="Sat, 9 Jul 2011 09:45:36 +0000"  >&lt;p&gt;I don&apos;t see (that doesn&apos;t mean they don&apos;t exist, my knowledge is certainly limited) any reasons to have values in the second treated in any different way than the ones from the first group.&lt;br/&gt;
While I understand that in most of cases these values are not going beyond the 32-bit integer range, I really don&apos;t see that much difference, for example between MongoCursor.Count and MapReduceResults.OutputCount &amp;#8211; both are results of a server-side query over a group of documents and are equally likely to produce same results if the M/R operation doesn&apos;t have many things to reduce.&lt;/p&gt;</comment>
                            <comment id="41356" author="rstam" created="Fri, 8 Jul 2011 16:36:58 +0000"  >&lt;p&gt;The following properties and methods are currently defined as Int32 but should have been Int64:&lt;/p&gt;

&lt;p&gt;MongoCollection&lt;br/&gt;
    Count&lt;/p&gt;

&lt;p&gt;MongoCursor&lt;br/&gt;
    Count&lt;br/&gt;
    Size&lt;/p&gt;

&lt;p&gt;MongoGridFSFileInfo&lt;br/&gt;
    Length&lt;/p&gt;

&lt;p&gt;The following properties and methods are also currently defined as Int32 but seem very unlikely to ever exceed that range (although theoretically they could):&lt;/p&gt;

&lt;p&gt;GeoNearResult&lt;br/&gt;
    BTreeLocations&lt;br/&gt;
    NumberScanned&lt;/p&gt;

&lt;p&gt;GetLastError&lt;br/&gt;
    DocumentsAffected&lt;/p&gt;

&lt;p&gt;MapReduceResults&lt;br/&gt;
    EmitCount&lt;br/&gt;
    OutputCount&lt;br/&gt;
    InputCount&lt;/p&gt;

&lt;p&gt;Any operation involving this second group that would cause a value outside the range of Int32 would probably time out first.&lt;/p&gt;

&lt;p&gt;My current thinking is to just change the first group to use Int64, and leave the second group alone. Any comments?&lt;/p&gt;</comment>
                            <comment id="38728" author="rstam" created="Wed, 22 Jun 2011 15:23:41 +0000"  >&lt;p&gt;You&apos;re right, Count should have returned an Int64.&lt;/p&gt;

&lt;p&gt;Probably the cleanest fix in the long run is to just change the return type to Int64. We might still be early enough (barely) in the life-cycle of the driver where a few minor breaking changes can still be tolerated (for example, version 1.1 had a few breaking changes).&lt;/p&gt;

&lt;p&gt;Note: whatever resolution is chosen for this JIRA, we should at the same time address all other places where an Int32 might not be large enough.&lt;/p&gt;</comment>
                    </comments>
                    <attachments>
                    </attachments>
                <subtasks>
                    </subtasks>
                <customfields>
                                                                                                                                                                                                                        <customfield id="customfield_10011" key="com.atlassian.jira.plugin.system.customfieldtypes:radiobuttons">
                        <customfieldname>Backwards Compatibility</customfieldname>
                        <customfieldvalues>
                                <customfieldvalue key="10011"><![CDATA[Minor Change]]></customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                <customfield id="customfield_15850" key="com.atlassian.jira.plugins.jira-development-integration-plugin:devsummary">
                        <customfieldname>Development</customfieldname>
                        <customfieldvalues>
                            
                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                    <customfield id="customfield_12550" key="com.pyxis.greenhopper.jira:gh-lexo-rank">
                        <customfieldname>Rank</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>2|hrh8sf:</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                <customfield id="customfield_10558" key="com.pyxis.greenhopper.jira:gh-global-rank">
                        <customfieldname>Rank (Obsolete)</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>14223</customfieldvalue>
                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                            </customfields>
    </item>
</channel>
</rss>