[SERVER-50778] "Cannot apply $bit" when $bit update grows an array Created: 03/Sep/20 Updated: 29/Oct/23 Resolved: 12/Feb/21 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | 4.9.0 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | pan chen | Assignee: | Ted Tuckman |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | qopt-team | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Attachments: |
|
||||||||||||||||||||||||||||||||||||||||||||
| Issue Links: |
|
||||||||||||||||||||||||||||||||||||||||||||
| Backwards Compatibility: | Minor Change | ||||||||||||||||||||||||||||||||||||||||||||
| Backport Requested: |
v4.4
|
||||||||||||||||||||||||||||||||||||||||||||
| Sprint: | Query 2020-11-30, Query 2020-12-14, Query 2020-12-28, Query 2021-01-11, Query 2021-01-25, Query Optimization 2021-02-22 | ||||||||||||||||||||||||||||||||||||||||||||
| Participants: | |||||||||||||||||||||||||||||||||||||||||||||
| Linked BF Score: | 29 | ||||||||||||||||||||||||||||||||||||||||||||
| Description |
|
I use the rs field to store an array of longs. When the rs field is stored to the subscript as eight bits, I use the bit operation to go to the ninth and tenth bits, and an error will be reported.
|
| Comments |
| Comment by Githook User [ 11/Mar/21 ] |
|
Author: {'name': 'Samuel Mercier', 'email': 'samontea@users.noreply.github.com', 'username': 'samontea'}Message: TIG-2919 Ban type errors caused by changes to array update (create field) semantics in |
| Comment by Githook User [ 11/Mar/21 ] |
|
Author: {'name': 'samontea', 'email': 'merciers.merciers@gmail.com', 'username': 'samontea'}Message: TIG-2919 Ban type errors caused by changes to array update (create field) semantics in |
| Comment by Githook User [ 11/Mar/21 ] |
|
Author: {'name': 'samontea', 'email': 'merciers.merciers@gmail.com', 'username': 'samontea'}Message: TIG-2919 Ban type errors caused by changes to array update (create field) semantics in |
| Comment by Githook User [ 12/Feb/21 ] |
|
Author: {'name': 'Ted Tuckman', 'email': 'ted.tuckman@mongodb.com', 'username': 'TedTuckman'}Message: |
| Comment by Githook User [ 11/Feb/21 ] |
|
Author: {'name': 'Ted Tuckman', 'email': 'TedTuckman@users.noreply.github.com', 'username': 'TedTuckman'}Message:
|
| Comment by Githook User [ 23/Oct/20 ] |
|
Author: {'name': 'Ted Tuckman', 'email': 'ted.tuckman@mongodb.com', 'username': 'TedTuckman'}Message: Revert " This reverts commit 16b59bd6236a90ad3d807a66ec2fe529e09cf0ec. |
| Comment by Eric Sedor [ 19/Oct/20 ] |
|
Hi hellotudou@outlook.com, we wanted to clarify that until this change is live, we recommend using numeric order instead of lexicographic order. That's because of the nature of this bug. We found that the updated array grows correctly except when lexicographic order differs from numeric order. You may still see issues if you try to manipulate a null 9th element with $bit if it was created implicitly when the 10th element was created. This is only really a problem when the kind of update being performed fails against a null value. Does this make sense? |
| Comment by pan chen [ 16/Oct/20 ] |
|
thank you,I temporarily update the array subscript in lexicographic order. |
| Comment by Githook User [ 15/Oct/20 ] |
|
Author: {'name': 'Ted Tuckman', 'email': 'ted.tuckman@mongodb.com', 'username': 'TedTuckman'}Message: |
| Comment by Eric Sedor [ 08/Sep/20 ] |
|
This looks to be an interaction between a few things:
Here, creating an element at rs.10 (the 11th element) in an array of 9 elements implicitly creates a 10th element (rs.9) that is explicitly null, which seems to cause the update to rs.9 to fail even though such an update would succeed on its own (as long as rs.9 was not already null). I'm passing this ticket on to an appropriate team for consideration. In the meantime, you can work around this by:
|
| Comment by Massimiliano Marcon [ 07/Sep/20 ] |
|
hellotudou@outlook.com this does not look like an issue of the MongoDB Shell. Moving to SERVER. |