Operational Defect Database

BugZero found this defect 2380 days ago.

MongoDB | 417857

[SERVER-30729] NumberLong compare with Number

Last update date:

10/27/2023

Affected products:

MongoDB Server

Affected releases:

3.4.7

Fixed releases:

No fixed releases provided.

Description:

Info

When compare number value with NumberLong, unexpect result got. PS: The following step get expect result on mongod 2.4, failed both 3.2 && 3.4. (other version not tested)

Top User Comments

geert.bosch commented on Tue, 22 Aug 2017 13:57:29 +0000: Old versions of MongoDB before 3.0 had an error on comparisons between floating point numbers and NumberLong for some values between 2 ** 53 and 2 ** 64. The NumberLong would be converted to a floating point number before comparison. This bug was fixed in SERVER-3719. tong20078 commented on Tue, 22 Aug 2017 05:59:56 +0000: @Geert Bosch IMO, look like the comparison between number and NumberLong is changed from mongodb 3.0; In mongodb 2.4, NumberLong is typecasted to number before comparison; and from mongodb 3.0, number is typecasted to NumberLong. E.G. in mongodb 2.4 > db.test.find({_id: 408457971232165500}) { "_id" : 408457971232165500 } > db.test.find({_id: 408457971232165504}) { "_id" : 408457971232165500 } > db.test.find({_id: NumberLong("408457971232165504")}) { "_id" : 408457971232165500 } > db.test.find({_id: NumberLong("408457971232165500")}) { "_id" : 408457971232165500 } in mongo 3.4 > db.test.save({_id: 408457971232165500, a: 1}) WriteResult( { "nMatched" : 0, "nUpserted" : 1, "nModified" : 0, "_id" : 408457971232165500 } ) > db.test.find({_id:NumberLong("408457971232165504")}) { "_id" : 408457971232165500, "a" : 1 } > db.test.find({_id:NumberLong("408457971232165500")}) > geert.bosch commented on Mon, 21 Aug 2017 22:47:05 +0000: The issue here is the conversion of the stored double precision number to a string. There actually is no double precision number 408457971232165500. Written in binary this number is 10110101011001000100101110001011000111110000100111001111100. This would require a mantissa of 57 bits, but the actual mantissa is only 53 bits for double precision numbers. The actual value of the stored double precision number is 408457971232165504, or 10110101011001000100101110001011000111110000100111010000000. You can see this as well by typing `NumberLong(408457971232165500)`, which results in NumberLong("408457971232165504"). So, you can find your document by using this number: > db.test.find({_id:NumberLong("408457971232165504")}) { "_id" : 408457971232165500, "a" : 1 } So, the data is stored correctly, but the double precision number is converted to text by the JavaScript interpreter using just 16 decimal digits, using trailing zeros . It appears that both the SpiderMonkey and V8 engines have this same behavior: only 16 significant digits are displayed as that is sufficient to convert back to the same double precision number. It would probably have been clearer if the number would have been output as 4.084579712321655e+17. Regardless, this is just an artifact of the JavaScript language and not something we can change. mark.agarunov commented on Mon, 21 Aug 2017 16:14:46 +0000: Hello tong20078, Thank you for the detailed report. I've been able to reproduce this behavior and we are currently investigating possible causes of this issue. Thanks, Mark tong20078 commented on Fri, 18 Aug 2017 11:14:43 +0000: Environment is wrong. => https://repo.mongodb.org/yum/redhat/6Server/mongodb-org/3.4/x86_64/RPMS/mongodb-org-server-3.4.7-1.el6.x86_64.rpm https://repo.mongodb.org/yum/redhat/6Server/mongodb-org/3.4/x86_64/RPMS/mongodb-org-shell-3.4.7-1.el6.x86_64.rpm

Additional Resources / Links

Share:

BugZero Risk Score

Coming soon

Status

Closed

Have you been affected by this bug?

cost-cta-background

Do you know how much operational outages are costing you?

Understand the cost to your business and how BugZero can help you reduce those costs.

Discussion

Login to read and write comments.

Have you ever...

had your data corrupted from a

VMware

bug?

Search:

...