[SERVER-24802] Database store a value different to the one provided as 64 bits long integer Created: 25/Jun/16 Updated: 21/Aug/17 Resolved: 26/Jun/16 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Internal Client, Internal Code |
| Affects Version/s: | 3.2.7 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Critical - P2 |
| Reporter: | TrustworthySystems [X] | Assignee: | Unassigned |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
|||||||||||||||||||||||||||||||||||||||||||
| Operating System: | ALL | |||||||||||||||||||||||||||||||||||||||||||
| Steps To Reproduce: | In a MongoDB Linux installation, following the Instructions at MongoDB Docs In Linux shell run the MongoDB shell client:
In the MongoDB shell client:
You can drop the collection and restart with a different number:
Here is a command line running sample:
|
|||||||||||||||||||||||||||||||||||||||||||
| Participants: | ||||||||||||||||||||||||||||||||||||||||||||
| Description |
|
Please, reroute me if this has a workaround for 64 bits, data handling (can't afford bits modifications by the database, or the database interface) When using the mongo shell client in Linux, storing a 64 bits long integer result in a stored value different in more than 60 bits. Storing .. 9223372036854775804 (0x7FFFFFFFFFFFFFFC) Storing .. 4611686018427387900 (0x3FFFFFFFFFFFFFFC) Storing .. 2305843009213693951 (0x1FFFFFFFFFFFFFFF) Storing .. 1152921504606846975 (0x0FFFFFFFFFFFFFFF) Storing ... 576460752303423487 (0x07FFFFFFFFFFFFFF) Storing ... 288230376151711743 (0x03FFFFFFFFFFFFFF) I manage to pin point the border of the problem, when the bit 52 is on, the minor bits appears to be rounded (This make match with the 53 bits of mantissa for the IEEE 754 64 bit double precision floating point), the maximum number assignable (in case of restart, with initialization) is: 9,007,199,254,740,991 Storing ...... 9007199254740991 (0x001FFFFFFFFFFFFF) |
| Comments |
| Comment by TrustworthySystems [X] [ 25/Jun/16 ] |
|
I test with your suggestion and save the 64 bit integer correctly, "−9223372036854775808" , ... , "-1" , "0" , "1" , ... , "9223372036854775807" managed as text. obviously this is not an internal issue, but a middle-ware issue, |
| Comment by Max Hirschhorn [ 25/Jun/16 ] |
|
The representation for Number values in JavaScript is as a double-precision 64-bit binary format IEEE 754 value. This is required by the ECMAScript specification: http://www.ecma-international.org/ecma-262/6.0/#sec-terms-and-definitions-number-value. The reason why you're observing a loss of precision in the value that was inserted is because you're passing a number that exceeds Number.MAX_SAFE_INTEGER to the NumberLong() constructor. More specifically, since 9223372036854775804 exceeds 2^53 - 1, the Number value cannot represent an integer exactly, so you end up with a loss of precision prior to calling the NumberLong() constructor itself. What you can do instead is pass the number as a numeric string to the NumberLonger() constructor, i.e. do NumberLong("9223372036854775804"). This will avoid any conversion to a Number value that would result in a loss of precision. Hope that helps, |