<!-- 
RSS generated by JIRA (9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66) at Thu Feb 08 02:56:53 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>[SERVER-1393] Support decimal numbers</title>
                <link>https://jira.mongodb.org/browse/SERVER-1393</link>
                <project id="10000" key="SERVER">Core Server</project>
                    <description>&lt;p&gt;Add a new BSON type for decimal numbers in MongoDB 3.4. This type will use the &lt;a href=&quot;https://en.wikipedia.org/wiki/Decimal128_floating-point_format&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;decimal128&lt;/a&gt; format as defined by the &lt;a href=&quot;https://en.wikipedia.org/wiki/IEEE_floating_point&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;IEEE 754&lt;/a&gt; standard and support up to 34 decimal digits and a range from -9.999999999999999999999999999999999&#215;10^6144 to +9.999999999999999999999999999999999&#215;10^6144.&lt;/p&gt;

&lt;p&gt;Decimal values will be treated like any other numeric type, and compare and sort correctly with other types based on actual numeric value. Operations on decimals are implemented in accordance with the standard, so a value of 0.10 will retain its trailing zeros while comparing equal to 0.1, 0.10000 etc.&lt;/p&gt;

&lt;p&gt;Original description: Please consider adding support for arbitrary-precision numbers. A lot of applications consider precision as a mission critical component and lack of support for high precision numbers makes it impossible to use MongoDB.&lt;/p&gt;</description>
                <environment></environment>
        <key id="12405">SERVER-1393</key>
            <summary>Support decimal numbers</summary>
                <type id="2" iconUrl="https://jira.mongodb.org/secure/viewavatar?size=xsmall&amp;avatarId=14711&amp;avatarType=issuetype">New Feature</type>
                                            <priority id="3" iconUrl="https://jira.mongodb.org/images/icons/priorities/major.svg">Major - P3</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="geert.bosch@mongodb.com">Geert Bosch</assignee>
                                    <reporter username="karl">karl seguin</reporter>
                        <labels>
                            <label>bson2</label>
                    </labels>
                <created>Sun, 11 Jul 2010 19:03:01 +0000</created>
                <updated>Mon, 15 Nov 2021 15:40:56 +0000</updated>
                            <resolved>Mon, 6 Jun 2016 21:55:10 +0000</resolved>
                                                    <fixVersion>3.3.8</fixVersion>
                                    <component>Usability</component>
                                        <votes>141</votes>
                                    <watches>111</watches>
                                                                                                                <comments>
                            <comment id="1288267" author="mitar" created="Wed, 8 Jun 2016 18:35:30 +0000"  >&lt;p&gt;Thanks for this measurement!&lt;/p&gt;</comment>
                            <comment id="1288257" author="geert.bosch" created="Wed, 8 Jun 2016 18:30:25 +0000"  >&lt;p&gt;In actual BSON documents, a field like x : NumberDecimal(&quot;0.02&quot;) will take 1 byte for the BSON type, 1 byte for &apos;x&apos;, 1 zero byte to terminate the name and 16 bytes for the 128-bit decimal, for a total of 19 bytes. The same field would take 11 bytes for a double. For documents including an _id field with an ObjectId, the total document size is 41 bytes for decimal and 33 for double and 22 bytes for a document with just _id. By default, MongoDB uses the &quot;snappy&quot; compression method. As a test I inserted documents as above with random decimal and double precision numbers between 0.00 and 9999.99 and checked final storage sizes. &lt;/p&gt;

&lt;div class=&apos;table-wrap&apos;&gt;
&lt;table class=&apos;confluenceTable&apos;&gt;&lt;tbody&gt;
&lt;tr&gt;
&lt;th class=&apos;confluenceTh&apos;&gt; inserted &lt;/th&gt;
&lt;th class=&apos;confluenceTh&apos;&gt; size &lt;/th&gt;
&lt;th class=&apos;confluenceTh&apos;&gt; storageSize &lt;/th&gt;
&lt;th class=&apos;confluenceTh&apos;&gt; compression &lt;/th&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td class=&apos;confluenceTd&apos;&gt; { }   &lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;  22 &lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;  11.8 &lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;  46.4%  &lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td class=&apos;confluenceTd&apos;&gt; { x : ####.## } &lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt; 33 &lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt; 17.0 &lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt; 48.5% &lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td class=&apos;confluenceTd&apos;&gt; {x : NumberDecimal(&quot;####.##&quot;) } &lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt; 41 &lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt; 20.0 &lt;/td&gt;
&lt;td class=&apos;confluenceTd&apos;&gt; 51.2% &lt;/td&gt;
&lt;/tr&gt;
&lt;/tbody&gt;&lt;/table&gt;
&lt;/div&gt;


&lt;p&gt;So, with default compression, decimal numbers take about 3 bytes more than doubles.&lt;/p&gt;
</comment>
                            <comment id="1286042" author="mitar" created="Tue, 7 Jun 2016 04:35:19 +0000"  >&lt;p&gt;How does this interoperate with compression? Are those values compressed when possible?&lt;/p&gt;</comment>
                            <comment id="1285765" author="geert.bosch" created="Mon, 6 Jun 2016 21:55:10 +0000"  >&lt;p&gt;Support for the decimal128 data type, supporting decimal values with up to 34 digits of precision, is now fully implemented including indexing and aggregation support.&lt;/p&gt;</comment>
                            <comment id="1244246" author="xgen-internal-githook" created="Fri, 22 Apr 2016 19:05:39 +0000"  >&lt;p&gt;Author:&lt;/p&gt;
{u&apos;username&apos;: u&apos;GeertBosch&apos;, u&apos;name&apos;: u&apos;Geert Bosch&apos;, u&apos;email&apos;: u&apos;geert@mongodb.com&apos;}
&lt;p&gt;Message: &lt;a href=&quot;https://jira.mongodb.org/browse/SERVER-1393&quot; title=&quot;Support decimal numbers&quot; class=&quot;issue-link&quot; data-issue-key=&quot;SERVER-1393&quot;&gt;&lt;del&gt;SERVER-1393&lt;/del&gt;&lt;/a&gt;: Include decimal support under control of server parameter&lt;br/&gt;
Branch: master&lt;br/&gt;
&lt;a href=&quot;https://github.com/mongodb/mongo/commit/8e13345122986b242811ebee1c0908a4fc01640c&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://github.com/mongodb/mongo/commit/8e13345122986b242811ebee1c0908a4fc01640c&lt;/a&gt;&lt;/p&gt;</comment>
                            <comment id="1244245" author="xgen-internal-githook" created="Fri, 22 Apr 2016 19:05:38 +0000"  >&lt;p&gt;Author:&lt;/p&gt;
{u&apos;username&apos;: u&apos;GeertBosch&apos;, u&apos;name&apos;: u&apos;Geert Bosch&apos;, u&apos;email&apos;: u&apos;geert@mongodb.com&apos;}
&lt;p&gt;Message: &lt;a href=&quot;https://jira.mongodb.org/browse/SERVER-1393&quot; title=&quot;Support decimal numbers&quot; class=&quot;issue-link&quot; data-issue-key=&quot;SERVER-1393&quot;&gt;&lt;del&gt;SERVER-1393&lt;/del&gt;&lt;/a&gt; Fix decimal library build on Windows&lt;br/&gt;
Branch: master&lt;br/&gt;
&lt;a href=&quot;https://github.com/mongodb/mongo/commit/dea2cdd594648d2409bc05f620f7854971d20470&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://github.com/mongodb/mongo/commit/dea2cdd594648d2409bc05f620f7854971d20470&lt;/a&gt;&lt;/p&gt;</comment>
                            <comment id="1244244" author="xgen-internal-githook" created="Fri, 22 Apr 2016 19:05:37 +0000"  >&lt;p&gt;Author:&lt;/p&gt;
{u&apos;username&apos;: u&apos;GeertBosch&apos;, u&apos;name&apos;: u&apos;Geert Bosch&apos;, u&apos;email&apos;: u&apos;geert@mongodb.com&apos;}
&lt;p&gt;Message: &lt;a href=&quot;https://jira.mongodb.org/browse/SERVER-1393&quot; title=&quot;Support decimal numbers&quot; class=&quot;issue-link&quot; data-issue-key=&quot;SERVER-1393&quot;&gt;&lt;del&gt;SERVER-1393&lt;/del&gt;&lt;/a&gt; Allow specifying BSON version to validate&lt;br/&gt;
Branch: master&lt;br/&gt;
&lt;a href=&quot;https://github.com/mongodb/mongo/commit/1a61f2e56e33da64cbf64090584e8da900f09241&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://github.com/mongodb/mongo/commit/1a61f2e56e33da64cbf64090584e8da900f09241&lt;/a&gt;&lt;/p&gt;</comment>
                            <comment id="1171270" author="geert.bosch" created="Thu, 11 Feb 2016 23:02:23 +0000"  >&lt;p&gt;We are planning to add a new BSON type for decimal numbers in MongoDB 3.4. This type will use the &lt;a href=&quot;https://en.wikipedia.org/wiki/Decimal128_floating-point_format&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;decimal128&lt;/a&gt; format as defined by the &lt;a href=&quot;https://en.wikipedia.org/wiki/IEEE_floating_point&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;IEEE 754&lt;/a&gt; standard and support up to 34 decimal digits and a range from -9.999999999999999999999999999999999&#215;10^6144 to +9.999999999999999999999999999999999&#215;10^6144.&lt;/p&gt;

&lt;p&gt;Decimal values will be treated like any other numeric type, and compare and sort correctly with other types based on actual numeric value. Operations on decimals are implemented in accordance with the standard, so a value of &lt;tt&gt;0.10&lt;/tt&gt; will retain its trailing zeros while comparing equal to &lt;tt&gt;0.1&lt;/tt&gt;, &lt;tt&gt;0.10000&lt;/tt&gt; etc.&lt;/p&gt;

&lt;p&gt;Please continue to watch this ticket for updates on these changes. Thanks all for your patience!&lt;/p&gt;</comment>
                            <comment id="1124351" author="johnnyshields" created="Thu, 31 Dec 2015 00:26:46 +0000"  >&lt;p&gt;Hi MongoDB team, may we please get a comment on this? BigDecimal is used in many applications (financial, etc). There are many half-baked solutions which attempt to solve this at the application layer (e.g. storing as string for reading + float for querying) but the problem would really be better solved in the DB itself.&lt;/p&gt;</comment>
                            <comment id="860446" author="sherifsabry20000@gmail.com" created="Sun, 22 Mar 2015 23:58:08 +0000"  >&lt;p&gt;So it has been 5 years since the ticket was opened! I think it is safe to assume that this won&apos;t be fixed unless a miracle happens.&lt;/p&gt;</comment>
                            <comment id="820505" author="ygbr@mac.com" created="Tue, 3 Feb 2015 20:40:38 +0000"  >&lt;p&gt;Is there a hint of light for this issue in the near future (post 3.0) ?&lt;br/&gt;
This is classified as high priority and has 116 votes from the community.&lt;/p&gt;

&lt;p&gt;This is indeed a much needed feature for anybody dealing with financial data. The solutions above work but they are far from effective, specially for using together with aggregations and sorting db-side...&lt;/p&gt;

&lt;p&gt;Are you guys seriously considering adding this datatype to the core db and the proper per-language decimal mappings on the drivers?&lt;/p&gt;

</comment>
                            <comment id="728107" author="x71c4l" created="Fri, 26 Sep 2014 15:19:15 +0000"  >&lt;p&gt;This would also be extremely helpful for us. Many of the workarounds are reasonable but are major setbacks if we attempt to use the aggregations framework.&lt;/p&gt;</comment>
                            <comment id="710249" author="benneq" created="Wed, 3 Sep 2014 07:40:19 +0000"  >&lt;p&gt;I want to add my +100 here, too.&lt;/p&gt;

&lt;p&gt;At the moment I handle it using a fixed size precision (8 in this case):&lt;br/&gt;
123.99 = { &quot;major&quot; : 123 , &quot;minor&quot; :  99000000 }&lt;br/&gt;
0.02 = { &quot;major&quot; : 0 , &quot;minor&quot; :  02000000 }&lt;/p&gt;

&lt;p&gt;This way I can sort my documents inside the DB and it&apos;s also possible to create a sum which can be used inside my Java code:&lt;br/&gt;
new BigDecimal((Long) source.get(&quot;major&quot;)).add(new BigDecimal((Long) source.get(&quot;minor&quot;)).movePointLeft(precision));&lt;/p&gt;

&lt;p&gt;But of course I can&apos;t compare those sums easily inside the db, which is bad.&lt;/p&gt;

&lt;p&gt;Concerning the other answers:&lt;br/&gt;
1. eBays method ( &lt;a href=&quot;http://www.technology-ebay.de/the-teams/mobile-de/blog/mapping-bigdecimals-with-morphia-for-mongodb.html&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;http://www.technology-ebay.de/the-teams/mobile-de/blog/mapping-bigdecimals-with-morphia-for-mongodb.html&lt;/a&gt; ) can&apos;t be sorted and can&apos;t be summed up inside db easily.&lt;br/&gt;
2. using a string will sort by character index: &quot;2&quot; &amp;gt; &quot;12&quot;&lt;br/&gt;
3. int64 was too small for my use case, that&apos;s why I used an object which results in about int120&lt;/p&gt;

&lt;p&gt;What about binary? Never thought about it. Can I sort / sum those values within a query?&lt;/p&gt;</comment>
                            <comment id="672598" author="reptilicus" created="Sun, 27 Jul 2014 05:14:03 +0000"  >&lt;p&gt;Agreed, this is really a must have. All the work arounds are quite honestly hideous. &lt;/p&gt;</comment>
                            <comment id="593899" author="lega" created="Fri, 23 May 2014 03:47:04 +0000"  >&lt;p&gt;Having a decimal type would be well. Anyway, now you have a few ways how can you store numbers:&lt;br/&gt;
1) string&lt;br/&gt;
2) float&lt;br/&gt;
3) int64 &apos;123.20&apos; -&amp;gt; 12320 (cents)&lt;br/&gt;
4) object &lt;/p&gt;
{ value:123, cents:20, currency:&apos;USD&apos; }
&lt;p&gt;5) binary array&lt;br/&gt;
...&lt;/p&gt;</comment>
                            <comment id="586875" author="cumminsdarin" created="Fri, 16 May 2014 20:52:21 +0000"  >&lt;p&gt;As a side note, in the 30+ years I&apos;ve been doing development, using floating point values have been rare and specific cases compared to other data types. If MongoDB defaulted decimal points values to fixed precision, and there was special annotation for using floating point values, it would make my day! &lt;img class=&quot;emoticon&quot; src=&quot;https://jira.mongodb.org/images/icons/emoticons/smile.png&quot; height=&quot;16&quot; width=&quot;16&quot; align=&quot;absmiddle&quot; alt=&quot;&quot; border=&quot;0&quot;/&gt;&lt;/p&gt;
</comment>
                            <comment id="586763" author="benbernardcs" created="Fri, 16 May 2014 19:42:18 +0000"  >&lt;p&gt;I agree with the above comments.  I like MongoDB, and I want to love it, but it really, really needs a decimal datatype.  I can&apos;t think of a single project I&apos;ve worked on that did not need decimal storage.  Seems like a glaring omission to me.&lt;/p&gt;</comment>
                            <comment id="565715" author="ygbr@mac.com" created="Mon, 28 Apr 2014 17:33:49 +0000"  >&lt;p&gt;Any news on this one?&lt;/p&gt;

&lt;p&gt;Storing financial / monetary data as  cents / decimal fractions is getting dumb after 4 years... anything we could do to help accelerate this issue? Is there anything major blocking it?&lt;/p&gt;

&lt;p&gt;Tks&lt;/p&gt;</comment>
                            <comment id="507105" author="nikkilocke" created="Fri, 28 Feb 2014 15:27:06 +0000"  >&lt;p&gt;Yes, mongo is unsuitable for a large number of applications because of this lack. Bite that bullet!&lt;/p&gt;</comment>
                            <comment id="502648" author="srehlander" created="Thu, 20 Feb 2014 21:27:23 +0000"  >&lt;p&gt;Agreed, this would be helpful for scientific applications.&lt;/p&gt;</comment>
                            <comment id="501536" author="dhgoldman" created="Wed, 19 Feb 2014 16:39:49 +0000"  >&lt;p&gt;Financial applications aren&apos;t the only use case. Scientific applications that require support for specific precision / scale would also be supported with this change.&lt;/p&gt;</comment>
                            <comment id="459659" author="james.tan" created="Thu, 21 Nov 2013 11:10:30 +0000"  >&lt;p&gt;FWIW, this is how eBay handles it: &lt;a href=&quot;http://www.technology-ebay.de/the-teams/mobile-de/blog/mapping-bigdecimals-with-morphia-for-mongodb.html&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;http://www.technology-ebay.de/the-teams/mobile-de/blog/mapping-bigdecimals-with-morphia-for-mongodb.html&lt;/a&gt;.&lt;/p&gt;</comment>
                            <comment id="402014" author="cumminsdarin" created="Tue, 13 Aug 2013 16:05:01 +0000"  >&lt;p&gt;I love how MongoDB is progressing and getting so much better with every release!&lt;/p&gt;

&lt;p&gt;However, this particular lack of functionality is a show stopper for us. We are making some large architectural changes in the near future and have been watching the MongoDB releases with anticipation. Almost all other NoSQL database support decimal types. We are going to be forced to make a decision soon and without decimal types it is doubtful that MongoDB will be on the list of possibilities.&lt;/p&gt;</comment>
                            <comment id="271934" author="vdimitrov@vladster.net" created="Thu, 21 Feb 2013 09:45:08 +0000"  >&lt;p&gt;Almost 3 years later and there is no solution to this? This is really a critical issue and narrows the use of this otherwise great DB a lot.&lt;/p&gt;</comment>
                            <comment id="107649" author="aochenyang" created="Sun, 8 Apr 2012 03:21:18 +0000"  >&lt;p&gt;@Dwight Merriman&lt;br/&gt;
1 vote for PSQL&apos;s implementation&lt;/p&gt;</comment>
                            <comment id="107131" author="carlosg" created="Thu, 5 Apr 2012 20:15:26 +0000"  >&lt;p&gt;@Dwight Merriman&lt;/p&gt;


&lt;p&gt;1 &amp;amp; 2 would be useful, but if 3 is easier to implement, it will solve most of the needs for storing money and inventory data.&lt;/p&gt;

&lt;p&gt;It could be: up to 16 decimal digits including 0 to 15 digits to the right of decimal. It could be stored using something like the old &quot;Packed Decimal&quot; format ( &lt;a href=&quot;http://en.wikipedia.org/wiki/Binary-coded_decimal#Packed_BCD&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;http://en.wikipedia.org/wiki/Binary-coded_decimal#Packed_BCD&lt;/a&gt; ), maybe with an extra byte for length and number of digits to the right of decimal.&lt;/p&gt;</comment>
                            <comment id="81360" author="cumminsdarin" created="Fri, 20 Jan 2012 21:44:11 +0000"  >&lt;p&gt;Here is an example of how Postgresql describes their Arbitrary Precision Numbers:&lt;/p&gt;

&lt;p&gt;&lt;a href=&quot;http://www.postgresql.org/docs/8.4/static/datatype-numeric.html&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;http://www.postgresql.org/docs/8.4/static/datatype-numeric.html&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;(See section 8.1.2)&lt;/p&gt;</comment>
                            <comment id="81304" author="dwight_10gen" created="Fri, 20 Jan 2012 18:38:18 +0000"  >&lt;p&gt;so exactly what should it be for example which of these :&lt;br/&gt;
1) arbitrary precision. if so, what standard? ideally based on some standard.&lt;br/&gt;
2) decimal64&lt;br/&gt;
3) some fixed precision decimal appropriate for money - e.g. 4 digits right of decimal&lt;/p&gt;</comment>
                            <comment id="78167" author="alexgadea" created="Fri, 6 Jan 2012 17:25:53 +0000"  >&lt;p&gt;Wanted to add my +10 vote on this and agree with Karl&apos;s comments.  I just had a large project choose to not use Mongo due to this glaring limitation.  Lots of very large datasets exist in the financial world and its a shame that Mongo will be shut out of consideration due to this very basic issue.&lt;/p&gt;</comment>
                            <comment id="77070" author="nicola" created="Mon, 2 Jan 2012 15:16:14 +0000"  >&lt;p&gt;This is indeed a show stopper for many financial/accounting applications. Actually I&apos;m surprised this is not getting (or so it seems by the vague responses) the attention it deserves.&lt;/p&gt;</comment>
                            <comment id="62720" author="andy222" created="Wed, 26 Oct 2011 09:58:59 +0000"  >&lt;p&gt;I just wanted to clarify something - when we talk about arbitrary-precision numbers, we are also talking about arbitrary-size numbers. So for instance 32 or 64 (or 128!) bits integers are &lt;b&gt;not&lt;/b&gt; good enough. There should be no limit in the size of a number whatsoever. Floats or doubles are also &lt;b&gt;not&lt;/b&gt; suitable. When I store the number I care about, I want it to be saved exactly as I want it. &lt;/p&gt;

&lt;p&gt;See Java BigDecimal or &lt;a href=&quot;http://www.php.net/manual/en/book.bc.php&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;PHP BCmath&lt;/a&gt; for reference implementations. You could even use libbcmath for this (LGPL license) if it makes sense.&lt;/p&gt;

&lt;p&gt;To recap, the DECIMAL data type should solve two problems:&lt;/p&gt;
&lt;ul class=&quot;alternate&quot; type=&quot;square&quot;&gt;
	&lt;li&gt;there should be no overflow&lt;/li&gt;
	&lt;li&gt;arbitrary precision&lt;/li&gt;
&lt;/ul&gt;


&lt;p&gt;Is there a time frame for this feature?&lt;/p&gt;</comment>
                            <comment id="38131" author="colinmollenhour" created="Sat, 18 Jun 2011 00:46:27 +0000"  >&lt;p&gt;Agree 100% with Karl. Mongo&apos;s mantra seems to be centered around (actually says this on the homepage) &quot;simplicity and power&quot;. Not having decimals definitely affects the simplicity of using Mongo for a large market.&lt;/p&gt;

&lt;p&gt;I suspect the reason this hasn&apos;t been given more attention is that due to MongoDb&apos;s schema-less nature there are additional challenges since you can&apos;t declare at the database layer that a field&apos;s value should be stored as &quot;decimal&quot;, and then the fact that there is no native/standard for decimals in many languages including javascript, although there is actually a proposal for a decimal data type in ecmascript&lt;span class=&quot;error&quot;&gt;&amp;#91;1&amp;#93;&lt;/span&gt;. It doesn&apos;t appear to be going anywhere fast so I&apos;m not holding my breath for 10gen to take this up..&lt;/p&gt;

&lt;p&gt;It seems the two main use-cases are for 1) working with huge numbers, and 2) dealing with decimal math and the ensuing calculation errors. Example for &lt;span class=&quot;error&quot;&gt;&amp;#91;2&amp;#93;&lt;/span&gt;:&lt;/p&gt;

&lt;p&gt;db.test.update({_id:&quot;math&quot;}, {_id:&quot;math&quot;, a:169.4}, true);&lt;br/&gt;
db.test.update({_id:&quot;math&quot;}, {$inc:{a:-121}});&lt;br/&gt;
db.test.findOne({_id:&quot;math&quot;});&lt;/p&gt;
{ &quot;_id&quot; : &quot;math&quot;, &quot;a&quot; : 48.400000000000006 }

&lt;p&gt;My proposal to deal with the 2nd use-case is rather than implement a fully-fledged decimal data type, what if users could set a decimal precision per-collection (documents remain schema-less) that would apply to all mongo doubles before they were stored? E.g.:&lt;/p&gt;

&lt;p&gt;db.createCollection(&quot;invoices&quot;, &lt;/p&gt;
{precision: 4}
&lt;p&gt;);&lt;/p&gt;

&lt;p&gt;Any floating point values in this collection would be rounded just like MySQL&apos;s decimal(16,4) for example. This certainly would not satisfy the requirements of a &quot;professional financial system&quot;, but there are &lt;b&gt;plenty&lt;/b&gt; of applications that still deal with arbitrary precision numbers in Mongo&apos;s target market and I think this solution would be sufficient in the large majority of them. Even MySQL&apos;s decimal used floating point math internally until 5.0 and that did the job for a lot of people despite not being ideal.&lt;/p&gt;

&lt;p&gt;&lt;span class=&quot;error&quot;&gt;&amp;#91;1&amp;#93;&lt;/span&gt; &lt;a href=&quot;http://wiki.ecmascript.org/doku.php?id=proposals:decimal&amp;amp;s=decimal&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;http://wiki.ecmascript.org/doku.php?id=proposals:decimal&amp;amp;s=decimal&lt;/a&gt;&lt;/p&gt;</comment>
                            <comment id="33488" author="jjg.denis.robert" created="Thu, 19 May 2011 11:04:20 +0000"  >&lt;p&gt;@Remon: I really don&apos;t see why you couldn&apos;t use MongoDB for financial apps (I certainly plan to do so). Of course, it&apos;s unlikely that MongoDB will be used as the datastore of record for transactions, but there&apos;s a lot more than just transactions in most financial applications. I think your view of the world is a little narrow here.&lt;/p&gt;

&lt;p&gt;In Java, BigDecimal is really nothing but a wrapper around BigInteger. Internal storage is just a integer. That&apos;s because there&apos;s really no difference between an integral type and a fixed-point type, other than the unit. As long as you convert all numbers to the base unit before doing calculations, there&apos;s no reason to have any issues other than over/underflow, and rounding issues which you can&apos;t avoid anyhow. &lt;/p&gt;

&lt;p&gt;But nevertheless, having a distinct fixed-point type is pretty important for any application that manipulates currency values, so I +1 this as well...&lt;/p&gt;</comment>
                            <comment id="28440" author="mnemosyn3" created="Fri, 8 Apr 2011 20:29:40 +0000"  >&lt;p&gt;@Karl: I just couldn&apos;t agree more! In particular because I&apos;m currently building a financial application with MongoDB and I&apos;m quite happy with it.&lt;/p&gt;

&lt;p&gt;@Darin: We&apos;ve been using the same workaround once, but it is really ugly when it comes to Map/Reduce: When multiplying two numbers, you&apos;d have to divide the result by 100M &amp;#8211; this gets really, really agonizing and is error-prone like hell. &lt;/p&gt;

&lt;p&gt;The C# driver serializes decimal to string which was a good decision I think: the numbers remain denormalized (&quot;1.0&quot; and &quot;1.000&quot; are different), but they can be used in map/reduce by prepending a &apos;+&apos; which forces JavaScript to convert to double. Of course, precision is still limited to double and normal queries are not available, but it worked out better for us than scaling the numbers. But eliminating the storage overhead and enabling queries on those numbers would still be great, of course.&lt;/p&gt;</comment>
                            <comment id="28358" author="cumminsdarin" created="Fri, 8 Apr 2011 17:19:17 +0000"  >&lt;p&gt;I have to agree with Karl.  I also work with financial data, albeit not in a &quot;banking&quot; type environment, and using the modifier operations to make changes is a huge plus.  We currently use a 64bit integer to encode monetary values (with an assumed precision of 4 decimal points) and while it does work, it isn&apos;t as straight forward as you might think.  (We were forced into this because the database we were using at the time would not handle anything but integers and floats).&lt;/p&gt;

&lt;p&gt;For example, if we want to escalate prices (stored as mentioned) by applying a percentage (also having to be stored as mentioned since they can also be a fraction) the result must be divided by 10000 (shifting the decimal point) to get the correct result.  Sure, simple, but must be done EVERYWHERE in the code.&lt;/p&gt;

&lt;p&gt;Many database creators (SQL Server, PostgreSQL, etc.) have begun life without the ability to handle fixed decimal (NUMERIC) types with the same attitude that &quot;it isn&apos;t needed&quot;.  However, all of them eventually were forced to put it in because it solves a lot of problems for developers.&lt;/p&gt;</comment>
                            <comment id="26479" author="karlseguin" created="Tue, 22 Mar 2011 13:09:59 +0000"  >&lt;p&gt;I just can&apos;t let the above FUD stand without a response. I hate to turn this feature request into some net-drama but...&lt;/p&gt;

&lt;p&gt;You aren&apos;t the only person with experience in financial systems and with financial companies. Your comment is as condescending as it is ignorant.&lt;/p&gt;

&lt;p&gt;It&apos;s called a two-phase commit and its extremely common in the relational world. If you&apos;ve never had to do a 2 phase commit across databases setup and designed in the early 90s, then you should consider yourself lucky (or possibly not nearly as experienced as you think you are with financial systems). &lt;/p&gt;

&lt;p&gt;In fact, it&apos;s exactly this type of system in which MongoDB is so well suited for in large financial institution - to act as a persistence cache for a modern application, to proxy away dated and impossible to change centralized relational databases. &lt;/p&gt;

&lt;p&gt;There will be cases where MongoDB won&apos;t be the right tool for the job, but by adding support for base-10 floats, that list will shrink. &lt;/p&gt;</comment>
                            <comment id="23937" author="remonvv" created="Tue, 15 Feb 2011 16:20:47 +0000"  >&lt;p&gt;I don&apos;t agree this is in any way a critical feature for MongoDB. Arbitrary decimals are not needed and actually a bad idea for the vast majority of use cases (read: I can&apos;t think of a single one).&lt;/p&gt;

&lt;p&gt;A few points :&lt;/p&gt;

&lt;p&gt;1) Anything that requires absolute consistency concerning financial transactions shouldn&apos;t use MongoDB in the first place. Use the right tool for the problem. The lack of transactional isolation, rollbacks, etc make it less than useful for this kind of problem. Use a fully ACID RDBMS.&lt;/p&gt;

&lt;p&gt;2) No professional financial system will ever use floating point values for currency representation for a plethora of reasons.&lt;/p&gt;

&lt;p&gt;3) As someone who actually built a number of financial systems that require some interoperability with other services; you cannot actually use arbitrary precision decimals because, as this discussion points out, a lot of systems/languages don&apos;t have support for that data type.&lt;/p&gt;

&lt;p&gt;4) Most financial systems I&apos;ve worked on or with have a smallest unit of currency designed into the system and that (integer) value is used throughout the app. Usually 1/1000ths of the currency unit but for the sake of clarity just think of it as working with cents/pennies instead of euros/dollars. This hardly qualifies as &quot;a complication&quot;. Basically all you&apos;re getting with arbitrary precision integers is an easier way to print them, nothing more. There&apos;s complete mathematical consistency between working with predefined units of currency and arbitrary precision numbers. In other words, your code will not be more complicated with the minor exception of the UI code which will need a single helper function to prettify the number.&lt;/p&gt;

&lt;p&gt;-1?&lt;/p&gt;
</comment>
                            <comment id="23783" author="eliot" created="Sat, 12 Feb 2011 19:40:00 +0000"  >&lt;p&gt;If you login you can vote on the left here.&lt;/p&gt;</comment>
                            <comment id="23769" author="firozansari" created="Sat, 12 Feb 2011 16:45:28 +0000"  >&lt;p&gt;+1 vote for decimal data type.&lt;/p&gt;

&lt;p&gt;Is there any place where mongodb community can vote for a feature or request?&lt;/p&gt;</comment>
                            <comment id="23558" author="mguidi86" created="Thu, 10 Feb 2011 10:37:11 +0000"  >&lt;p&gt;There is some news about it??&lt;/p&gt;

&lt;p&gt;Work with decimal is really important, this features can&apos;t miss. If you deal with money you can&apos;t work with float or double.&lt;/p&gt;
</comment>
                            <comment id="19542" author="mnemosyn3" created="Sat, 23 Oct 2010 01:11:14 +0000"  >&lt;p&gt;Scott,&lt;br/&gt;
you shouldn&apos;t take this too lightly. I figured it comes down to the query, and the code you posted is in fact wrong. Let&apos;s explore this simple javascript example:&lt;br/&gt;
db.test.insert({_id : 1, val : new NumberLong(&quot;9223372036854775806&quot;)});&lt;br/&gt;
db.test.insert({_id : 2, val : new NumberLong(&quot;9223372036854775805&quot;)});&lt;/p&gt;

&lt;p&gt;Note that the large numbers correspond to long.MaxValue and long.MaxValue - 1. &lt;br/&gt;
long.MaxValue is the largest allowed signed 64 bit integer, as the name suggests. More to the point, this is 2^63-2. You cannot just use random &apos;123123&apos; numbers when talking about precision issues.&lt;/p&gt;

&lt;p&gt;// This will FAIL &lt;span class=&quot;error&quot;&gt;&amp;#91;does not find any results&amp;#93;&lt;/span&gt;, because the argument is apparently interpreted as double, and double&apos;s precision is insufficient to resolve the difference&lt;br/&gt;
db.test.find({ val : {$gt : 9223372036854775805 }});&lt;/p&gt;

&lt;p&gt;// This will return the expected 1 result.&lt;br/&gt;
db.test.find({ val : {$gt : new NumberLong(&quot;9223372036854775805&quot;)}});&lt;/p&gt;

&lt;p&gt;I believe at least one driver incorrectly implements this.&lt;/p&gt;</comment>
                            <comment id="19541" author="scotthernandez" created="Sat, 23 Oct 2010 00:50:10 +0000"  >&lt;p&gt;Christopher:&lt;/p&gt;

&lt;p&gt;Javascript is not involved for queries (at least not the ones you used). It is used for MR and that is why having javascript support for all the data-types is important, but unrelated to this request.&lt;/p&gt;

&lt;p&gt;I don&apos;t know what language that is (maybe python), but in javascript there is no &quot;long&quot; variable/class.&lt;/p&gt;

&lt;p&gt;&amp;gt; long.MaxValue&lt;br/&gt;
Fri Oct 22 17:32:56 ReferenceError: long is not defined (shell):0&lt;/p&gt;

&lt;p&gt;Here is a simple test from the shell (javascript)&lt;/p&gt;

&lt;p&gt;&amp;gt; db.test.insert({_id:1, val:NumberLong(&quot;123123123123&quot;)})&lt;br/&gt;
&amp;gt; db.test.insert({_id:2, val:123123123123})&lt;/p&gt;

&lt;p&gt;&amp;gt; db.test.find({val:{$type:18}}) //64bit signed value&lt;/p&gt;
{ &quot;_id&quot; : 1, &quot;val&quot; : NumberLong(&quot;123123123123&quot;) }

&lt;p&gt;&amp;gt; db.test.find({val:{$type:1}}) // 64bit fp (double &amp;#8211; javascript number)&lt;/p&gt;
{ &quot;_id&quot; : 2, &quot;val&quot; : 123123123123 }

&lt;p&gt;&amp;gt; db.test.find(&lt;/p&gt;
{val:123123123123}
&lt;p&gt;)&lt;/p&gt;
{ &quot;_id&quot; : 1, &quot;val&quot; : NumberLong(&quot;123123123123&quot;) }
{ &quot;_id&quot; : 2, &quot;val&quot; : 123123123123 }


&lt;p&gt;Everything seems fine &lt;img class=&quot;emoticon&quot; src=&quot;https://jira.mongodb.org/images/icons/emoticons/smile.png&quot; height=&quot;16&quot; width=&quot;16&quot; align=&quot;absmiddle&quot; alt=&quot;&quot; border=&quot;0&quot;/&gt;&lt;/p&gt;

&lt;p&gt;&amp;gt; db.test.find({val:{$gt:123123123123}})&lt;/p&gt;
{ &quot;_id&quot; : 3, &quot;val&quot; : 9223372036854776000 }
{ &quot;_id&quot; : 4, &quot;val&quot; : NumberLong(&quot;9223372036854774000&quot;) }

&lt;p&gt;&amp;gt; db.test.find({val:{$gte:123123123123}})&lt;/p&gt;
{ &quot;_id&quot; : 1, &quot;val&quot; : NumberLong(&quot;123123123123&quot;) }
{ &quot;_id&quot; : 2, &quot;val&quot; : 123123123123 }
{ &quot;_id&quot; : 3, &quot;val&quot; : 9223372036854776000 }
{ &quot;_id&quot; : 4, &quot;val&quot; : NumberLong(&quot;9223372036854774000&quot;) }

&lt;p&gt;For reference here is list of types: &lt;a href=&quot;http://bsonspec.org/#/specification&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;http://bsonspec.org/#/specification&lt;/a&gt;, and you can see $type section here: &lt;a href=&quot;http://www.mongodb.org/display/DOCS/Advanced+Queries#AdvancedQueries-%7B%7B%24type%7D%7D&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;http://www.mongodb.org/display/DOCS/Advanced+Queries#AdvancedQueries-%7B%7B%24type%7D%7D&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;PS. I think you need some sleep &lt;img class=&quot;emoticon&quot; src=&quot;https://jira.mongodb.org/images/icons/emoticons/smile.png&quot; height=&quot;16&quot; width=&quot;16&quot; align=&quot;absmiddle&quot; alt=&quot;&quot; border=&quot;0&quot;/&gt;&lt;/p&gt;

&lt;p&gt;If you have more questions about data-types you might want to take it up on the list. It is more distracting to others here.&lt;/p&gt;</comment>
                            <comment id="19540" author="mnemosyn3" created="Sat, 23 Oct 2010 00:04:09 +0000"  >&lt;p&gt;Scott, either I&apos;m just too exhausted (it&apos;s 2am here), or there&apos;s a MAJOR bug then:&lt;/p&gt;

&lt;p&gt;&amp;gt;&amp;gt; NumberLong class that represents the stored 64bit signed values in the shell/js &lt;br/&gt;
but isn&apos;t js invoked for queries and Map/Reduce operations?&lt;/p&gt;

&lt;p&gt;I just did this:&lt;br/&gt;
new &lt;/p&gt;
{Long = long.MaxValue }
&lt;p&gt;;&lt;br/&gt;
new &lt;/p&gt;
{Long = long.MaxValue - 1}
&lt;p&gt;;&lt;/p&gt;

&lt;p&gt;storing these to MongoDB and fetching them with a query&lt;br/&gt;
db.TestItem.find({&quot;Long&quot; : &lt;/p&gt;
{ $gt : 9223372036854775806 }
&lt;p&gt; }); &lt;br/&gt;
// No results! But there is an element which is one larger.&lt;br/&gt;
db.TestItem.find({&quot;Long&quot; : &lt;/p&gt;
{ $gt : 9223372036854775406 }
&lt;p&gt; }); &lt;br/&gt;
// &lt;b&gt;still&lt;/b&gt; No results! But there are two elements which are a lot larger..&lt;br/&gt;
db.TestItem.find({&quot;Long&quot; : &lt;/p&gt;
{ $gt : 9223372036854775106 }
&lt;p&gt; }); &lt;br/&gt;
// &lt;b&gt;two&lt;/b&gt; results now! Typical floating-point behaviour --&amp;gt; double is used behind the scenes, and there&apos;s no real Int64 support?!&lt;/p&gt;

&lt;p&gt;Don&apos;t let that JavaScript deficiencies crawl in...&lt;/p&gt;</comment>
                            <comment id="19538" author="scotthernandez" created="Fri, 22 Oct 2010 23:19:22 +0000"  >&lt;p&gt;Nope, there is no storing 64bit values as string in the server. Some client/driver may do that but it would be wrong.&lt;/p&gt;

&lt;p&gt;There is a special NumberLong class that represents the stored 64bit signed values in the shell/js since it isn&apos;t natively supported. &lt;/p&gt;</comment>
                            <comment id="19535" author="mnemosyn3" created="Fri, 22 Oct 2010 22:45:56 +0000"  >&lt;p&gt;Paul, &lt;br/&gt;
IEEE 754-2008 also specifies how to perform operations on base-10 floats. These representations are exact as long as they stay in the range of allowed values, much like int is exact. base-2 representations are also &apos;exact&apos; in binary form in their allowed value range, but human interaction is base-10 &amp;#8211; that&apos;s where the trouble originates.&lt;br/&gt;
I can see your point in missing support from the JavaScript side, but it&apos;s apparent lack of &lt;b&gt;precise&lt;/b&gt; numbers is a huge problem for financial applications. Given the fact that JavaScript does not even support integers (larger than 32 bit), we cannot fall back to fixed-point arithmetic either. As far as I can see, MongoDB will already employ an ugly hack to represent 64-bit integers by falling back to a string representation if numbers grow very large, correct? Talking about headache... &lt;img class=&quot;emoticon&quot; src=&quot;https://jira.mongodb.org/images/icons/emoticons/smile.png&quot; height=&quot;16&quot; width=&quot;16&quot; align=&quot;absmiddle&quot; alt=&quot;&quot; border=&quot;0&quot;/&gt;&lt;/p&gt;

&lt;p&gt;Performance is mostly a question of precision requirements: right now I might have to pull all items from the database and do the arithmetic myself; that&apos;s definitely slower than a base-10 implementation on the server-side. And we might just find a difference of two cents &lt;img class=&quot;emoticon&quot; src=&quot;https://jira.mongodb.org/images/icons/emoticons/wink.png&quot; height=&quot;16&quot; width=&quot;16&quot; align=&quot;absmiddle&quot; alt=&quot;&quot; border=&quot;0&quot;/&gt;&lt;/p&gt;</comment>
                            <comment id="19248" author="csirac2" created="Sat, 16 Oct 2010 01:21:42 +0000"  >&lt;p&gt;As discussed on IRC, while it would be nice, floats aren&apos;t designed for &apos;exact&apos; representation of numbers (base-10, base-2 or otherwise). IEEE-754 gives a way to &lt;b&gt;store&lt;/b&gt; floats but actually using them on hardware with an FPU that&apos;s hard-wired for base-2 floats is less than ideal.&lt;/p&gt;

&lt;p&gt;Additionally, ECMA-262 4th edition&apos;s suggestion of a &apos;use decimal&apos; directive for base-10 floats was obviously dropped (no mention of it in 5th edition). Even if it weren&apos;t dropped, I&apos;m not sure the major JS engine implementers are taking much notice of ECMA-262 roadmap anyway.&lt;/p&gt;

&lt;p&gt;So at first glance it seems unlikely that any the of the javascript engines mongodb is likely to work with will support base-10 floats any time soon, although I could be wrong.&lt;/p&gt;

&lt;p&gt;I don&apos;t know about others, but for best performance we depend on server-side js in mongo to deliver only  absolutely relevant results back to clients, and it seems that a variable radix float representation in the DB would horribly break/complicate the JS side of things, unless you had some sort of global conf to set the float type for all floats that are stored and used in your entire mongo cluster.&lt;/p&gt;

&lt;p&gt;Mixing base-10 and base-2 floats in the same system, especially with a query language that does not even support base-10 floats let alone have any mechanism to support different types of floats simultaneously (much less perform an operation involving both types!) sounds like a massive headache &lt;img class=&quot;emoticon&quot; src=&quot;https://jira.mongodb.org/images/icons/emoticons/smile.png&quot; height=&quot;16&quot; width=&quot;16&quot; align=&quot;absmiddle&quot; alt=&quot;&quot; border=&quot;0&quot;/&gt;&lt;/p&gt;

&lt;p&gt;Edit: I just found a reference to IBM&apos;s POWER6 architecture which apparently &apos;fully implements&apos; IEEE 754-2008 (I assume that includes arbitrary radix arithmetic), so there you go - are there many mongo users on zSeries mainframes? &lt;img class=&quot;emoticon&quot; src=&quot;https://jira.mongodb.org/images/icons/emoticons/smile.png&quot; height=&quot;16&quot; width=&quot;16&quot; align=&quot;absmiddle&quot; alt=&quot;&quot; border=&quot;0&quot;/&gt; &lt;/p&gt;</comment>
                            <comment id="18311" author="turjakas" created="Fri, 17 Sep 2010 13:02:39 +0000"  >&lt;p&gt;+1 vote for this feature. I need this for representing prices, which need to be exact. And the natural counterpart data-type in the Java driver would be Java&apos;s BigDecimal.&lt;/p&gt;</comment>
                            <comment id="16457" author="mnemosyn3" created="Wed, 4 Aug 2010 11:25:47 +0000"  >&lt;p&gt;I believe this is a major issue and it would be a big step forward for MongoDB if decimal support was implemented. However, I think the current description of this issue is somewhat misleading:&lt;/p&gt;

&lt;p&gt;Decimal is a floating point type of fixed size, thus not of &apos;arbitrary precision&apos;, even though some ruby documentations say so. We should be clear what we talk about here, exactly. I think there is little use for real arbitrary precision and from the foregoing discussion it seems people think about an IEEE floating point decimal here. The point in decimal is that they use a different base (namely ten instead of two), so simple values such as 0.1 can be represented exactly, which is not possible with binary floating point, see &lt;a href=&quot;http://stackoverflow.com/questions/618535/what-is-the-difference-between-decimal-float-and-double-in-c&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;http://stackoverflow.com/questions/618535/what-is-the-difference-between-decimal-float-and-double-in-c&lt;/a&gt; for a discussion.&lt;/p&gt;

&lt;p&gt;According to Wikipedia, IEEE754-2008 specifies floating point data types, both in binary and decimal, all of which could be interesting for MongoDB (even the 64 bit decimal type), see &lt;a href=&quot;http://en.wikipedia.org/wiki/IEEE_754-2008&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;http://en.wikipedia.org/wiki/IEEE_754-2008&lt;/a&gt;. Since this is standardized I expect most programming languages to have their decimal implementations based on it, so it will we widely available to MongoDB users.&lt;/p&gt;</comment>
                            <comment id="16419" author="raroldan" created="Tue, 3 Aug 2010 13:00:28 +0000"  >&lt;p&gt;This is quite a show stopper for financial type applications in .net land. &lt;br/&gt;
Eliot, Could you please elaborate on your answer (thanks).&lt;/p&gt;</comment>
                            <comment id="15641" author="eliot" created="Mon, 12 Jul 2010 08:36:31 +0000"  >&lt;p&gt;If you make them binary sortable then they are.&lt;/p&gt;</comment>
                            <comment id="15640" author="karlseguin" created="Mon, 12 Jul 2010 08:28:20 +0000"  >&lt;p&gt;But you can&apos;t filter on it - which is pretty common.&lt;/p&gt;</comment>
                            <comment id="15636" author="eliot" created="Sun, 11 Jul 2010 23:40:17 +0000"  >&lt;p&gt;You can always use a custom binary subtype.&lt;br/&gt;
Or just binary&lt;/p&gt;</comment>
                    </comments>
                <issuelinks>
                            <issuelinktype id="10011">
                    <name>Depends</name>
                                            <outwardlinks description="depends on">
                                        <issuelink>
            <issuekey id="223689">SERVER-19703</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="223916">SERVER-19735</issuekey>
        </issuelink>
                            </outwardlinks>
                                                                <inwardlinks description="is depended on by">
                                        <issuelink>
            <issuekey id="270544">CSHARP-1594</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="268747">DRIVERS-288</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="270545">JAVA-2140</issuekey>
        </issuelink>
                            </inwardlinks>
                                    </issuelinktype>
                            <issuelinktype id="10320">
                    <name>Documented</name>
                                                                <inwardlinks description="is documented by">
                                        <issuelink>
            <issuekey id="300400">DOCS-8299</issuekey>
        </issuelink>
                            </inwardlinks>
                                    </issuelinktype>
                            <issuelinktype id="10012">
                    <name>Related</name>
                                            <outwardlinks description="related to">
                                        <issuelink>
            <issuekey id="283980">DOCS-7792</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="30870">SERVER-4996</issuekey>
        </issuelink>
                            </outwardlinks>
                                                                <inwardlinks description="is related to">
                                        <issuelink>
            <issuekey id="223002">SERVER-19624</issuekey>
        </issuelink>
                            </inwardlinks>
                                    </issuelinktype>
                    </issuelinks>
                <attachments>
                    </attachments>
                <subtasks>
                    </subtasks>
                <customfields>
                                                <customfield id="customfield_10050" key="com.atlassian.jira.toolkit:comments">
                        <customfieldname># Replies</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>52.0</customfieldvalue>
                        </customfieldvalues>
                    </customfield>
                                                                <customfield id="customfield_18555" key="com.onresolve.jira.groovy.groovyrunner:scripted-field">
                        <customfieldname># of Sprints</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>1.0</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                                                                                                                                                                                                                            <customfield id="customfield_10011" key="com.atlassian.jira.plugin.system.customfieldtypes:radiobuttons">
                        <customfieldname>Backwards Compatibility</customfieldname>
                        <customfieldvalues>
                                <customfieldvalue key="10012"><![CDATA[Major Change]]></customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                                                                                                    <customfield id="customfield_13552" key="com.go2group.jira.plugin.crm:crm_generic_field">
                        <customfieldname>Case</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue><![CDATA[[500A000000UaXmjIAF]]]></customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                                                                                                            <customfield id="customfield_10055" key="com.atlassian.jira.ext.charting:firstresponsedate">
                        <customfieldname>Date of 1st Reply</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>Sun, 11 Jul 2010 23:40:17 +0000</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                <customfield id="customfield_10052" key="com.atlassian.jira.toolkit:dayslastcommented">
                        <customfieldname>Days since reply</customfieldname>
                        <customfieldvalues>
                                        7 years, 36 weeks ago
    
                        </customfieldvalues>
                    </customfield>
                                                                <customfield id="customfield_18254" key="com.onresolve.jira.groovy.groovyrunner:scripted-field">
                        <customfieldname>Dependencies</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue><![CDATA[<s><a href='https://jira.mongodb.org/browse/SERVER-19703'>SERVER-19703</a></s>, <s><a href='https://jira.mongodb.org/browse/SERVER-19735'>SERVER-19735</a></s>]]></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_10857" key="com.pyxis.greenhopper.jira:gh-epic-link">
                        <customfieldname>Epic Link</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>PM-165</customfieldvalue>
                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                <customfield id="customfield_10057" key="com.atlassian.jira.toolkit:lastusercommented">
                        <customfieldname>Last comment by Customer</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>true</customfieldvalue>
                        </customfieldvalues>
                    </customfield>
                                                                                            <customfield id="customfield_10056" key="com.atlassian.jira.toolkit:lastupdaterorcommenter">
                        <customfieldname>Last commenter</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>luke.bonanomi@mongodb.com</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                <customfield id="customfield_11151" key="com.atlassian.jira.toolkit:LastCommentDate">
                        <customfieldname>Last public comment date</customfieldname>
                        <customfieldvalues>
                            7 years, 36 weeks ago
                        </customfieldvalues>
                    </customfield>
                                                                                                                        <customfield id="customfield_10000" key="com.atlassian.jira.plugin.system.customfieldtypes:radiobuttons">
                        <customfieldname>Old_Backport</customfieldname>
                        <customfieldvalues>
                                <customfieldvalue key="10000"><![CDATA[No]]></customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                <customfield id="customfield_10051" key="com.atlassian.jira.toolkit:participants">
                        <customfieldname>Participants</customfieldname>
                        <customfieldvalues>
                                        <customfieldvalue>alexgadea</customfieldvalue>
            <customfieldvalue>andy222</customfieldvalue>
            <customfieldvalue>aochenyang</customfieldvalue>
            <customfieldvalue>benbernardcs</customfieldvalue>
            <customfieldvalue>benneq</customfieldvalue>
            <customfieldvalue>x71c4l</customfieldvalue>
            <customfieldvalue>carlosg</customfieldvalue>
            <customfieldvalue>mnemosyn3</customfieldvalue>
            <customfieldvalue>colinmollenhour</customfieldvalue>
            <customfieldvalue>dhgoldman</customfieldvalue>
            <customfieldvalue>cumminsdarin</customfieldvalue>
            <customfieldvalue>jjg.denis.robert</customfieldvalue>
            <customfieldvalue>dwight@mongodb.com</customfieldvalue>
            <customfieldvalue>eliot</customfieldvalue>
            <customfieldvalue>firozansari</customfieldvalue>
            <customfieldvalue>geert.bosch@mongodb.com</customfieldvalue>
            <customfieldvalue>xgen-internal-githook</customfieldvalue>
            <customfieldvalue>james.tan</customfieldvalue>
            <customfieldvalue>reptilicus</customfieldvalue>
            <customfieldvalue>johnnyshields</customfieldvalue>
            <customfieldvalue>karl</customfieldvalue>
            <customfieldvalue>karlseguin</customfieldvalue>
            <customfieldvalue>mguidi86</customfieldvalue>
            <customfieldvalue>turjakas</customfieldvalue>
            <customfieldvalue>nicola</customfieldvalue>
            <customfieldvalue>nikkilocke</customfieldvalue>
            <customfieldvalue>mitar</customfieldvalue>
            <customfieldvalue>lega</customfieldvalue>
            <customfieldvalue>csirac2</customfieldvalue>
            <customfieldvalue>raroldan</customfieldvalue>
            <customfieldvalue>remonvv</customfieldvalue>
            <customfieldvalue>scotthernandez</customfieldvalue>
            <customfieldvalue>srehlander</customfieldvalue>
            <customfieldvalue>sherifsabry20000@gmail.com</customfieldvalue>
            <customfieldvalue>vdimitrov@vladster.net</customfieldvalue>
            <customfieldvalue>ygbr@mac.com</customfieldvalue>
    
                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                        <customfield id="customfield_14254" key="com.pyxis.greenhopper.jira:gh-lexo-rank">
                        <customfieldname>Product Rank</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>1|hrpjsv:</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                <customfield id="customfield_12550" key="com.pyxis.greenhopper.jira:gh-lexo-rank">
                        <customfieldname>Rank</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>2|hrczfj:</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                <customfield id="customfield_10558" key="com.pyxis.greenhopper.jira:gh-global-rank">
                        <customfieldname>Rank (Obsolete)</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>4957</customfieldvalue>
                        </customfieldvalues>
                    </customfield>
                                                                                            <customfield id="customfield_23361" key="com.onresolve.jira.groovy.groovyrunner:scripted-field">
                        <customfieldname>Requested By</customfieldname>
                        <customfieldvalues>
                                

                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                        <customfield id="customfield_10557" key="com.pyxis.greenhopper.jira:gh-sprint">
                        <customfieldname>Sprint</customfieldname>
                        <customfieldvalues>
                                <customfieldvalue id="1097">Integrate+Tuning 16 (06/24/16)</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                                                                                                            <customfield id="customfield_10053" key="com.atlassian.jira.ext.charting:timeinstatus">
                        <customfieldname>Time In Status</customfieldname>
                        <customfieldvalues>
                            
                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                                                                                                                                                                                                                                                        <customfield id="customfield_22870" key="com.onresolve.jira.groovy.groovyrunner:scripted-field">
                        <customfieldname>Triagers</customfieldname>
                        <customfieldvalues>
                                

                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                                                                                                                                                                    <customfield id="customfield_14350" key="com.pyxis.greenhopper.jira:gh-lexo-rank">
                        <customfieldname>serverRank</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>1|hriy9z:</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                    </customfields>
    </item>
</channel>
</rss>