[SERVER-5424] Shell doesn't re-save retrieved integers in an array as integers (converted to 64-bit float) Created: 27/Mar/12 Updated: 10/May/22 |
|
| Status: | Backlog |
| Project: | Core Server |
| Component/s: | JavaScript, Shell |
| Affects Version/s: | 2.0.4 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Tyler Brock | Assignee: | DO NOT USE - Backlog - Platform Team |
| Resolution: | Unresolved | Votes: | 7 |
| Labels: | move-sa, platforms-re-triaged | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||||||||||||||
| Operating System: | ALL | ||||||||||||||||||||||||||||||||
| Participants: | |||||||||||||||||||||||||||||||||
| Case: | (copied to CRM) | ||||||||||||||||||||||||||||||||
| Description |
The size increases because they are being re-saved as 64-bit floats and it increases by more than just 6 bytes because of padding factor. |
| Comments |
| Comment by Steven Vannelli [ 10/May/22 ] | |||||||||||
|
Moving this ticket to the Backlog and removing the "Backlog" fixVersion as per our latest policy for using fixVersions. | |||||||||||
| Comment by Hassan Faghihi [ 19/Jul/19 ] | |||||||||||
|
i have issue with these data type getting updating.... the complete issue, query and dump data can be found in here:
I'm implementing .Net Identity for authentication | |||||||||||
| Comment by Tyler Brock [ 25/Nov/13 ] | |||||||||||
|
The mongo shell currently converts BSON int32 values to doubles when going from Mongo to V8. This gives the current implementation two rather nice properties that are depended upon heavily by users of the shell and by the database itself:
If we fix the root problem both of these properties disappear.
The second property loss arises because comparison in Javascript works differently between objects (user defined types) than it does between numbers (an internal type). Comparing two objects of the same type, for example, is done by identity and not by value. So while it is true that 7 == 7 evaluates as true in JavaScript, NumberInt(7) == NumberInt(7) does not. Many applications depend on the ability to compare these numbers using == and === (including mongod itself) such as when comparing replica set config versions for example. Further discussion about how to resolve this particular issue is required. This appears to only be a problem when the integers happen to be in an array but this is simply a case of an optimization obscuring the bug in the most common cases. Most of the time, the mongo shell converts the 32-bit integers to doubles for display but winds up using the original internal BSON representation when saving them back to the database. Therefore, even though in the shell they have the wrong type and are displayed incorrectly it doesn't wind up making a difference. However, if the integers are in an array, the mongo shell converts them to JavaScript number form internally so that V8 can optimize for processing an array of doubles. V8 is able to process arrays of doubles much faster than arrays of objects when it injects optimized code into the interpreter. In this scenario, the internal BSON representation is invalidated and the objects are re-serialzed as doubles upon saving them to the database. | |||||||||||
| Comment by Daniel Pasette (Inactive) [ 24/Nov/13 ] | |||||||||||
|
Can't make the proposed change at this time as it changes behavior for many dependent tests and scripts. | |||||||||||
| Comment by Githook User [ 20/Nov/13 ] | |||||||||||
|
Author: {u'username': u'ehershey', u'name': u'Ernie Hershey', u'email': u'ernie.hershey@10gen.com'}Message: Revert "SERVER-5424 use NumberInt function template in mongoToV8Element" This reverts commit 4a3d5aa6f430530b8a44e581c430176e15da19c2. | |||||||||||
| Comment by Githook User [ 19/Nov/13 ] | |||||||||||
|
Author: {u'username': u'TylerBrock', u'name': u'Tyler Brock', u'email': u'tyler.brock@gmail.com'}Message: SERVER-5424 use NumberInt function template in mongoToV8Element Signed-off-by: Matt Kangas <matt.kangas@mongodb.com> | |||||||||||
| Comment by Tyler Brock [ 15/Nov/13 ] | |||||||||||
|
This is actually a better example (note: $type: 16 is a 32 bit int and $type: 1 is a double):
| |||||||||||
| Comment by Xiaomei Liu [ 14/Feb/13 ] | |||||||||||
|
We had similar issue and the issue is causing retrieving failure after read-update-save operation. C:\windows\system32>mongo // Create a document with an Int32 field and an Int32 array field: > db.testCollection.insert( {a:NumberInt(1),b:[NumberInt(2)]}) // Search for a document with an Int32 'b' field. // Read this document into a local variable. // Save the document (without having made any modifications). // Search for a document with an Int32 'b' field. // Search for a document with a Double 'b' field. // Search for a document with an Int32 'a' field. Conclusion: The Mongo Shell does not properly preserve Int32s stored in arrays. |