-
Type: Bug
-
Resolution: Duplicate
-
Priority: Major - P3
-
None
-
Affects Version/s: None
-
Component/s: Querying
-
Query
-
ALL
-
(copied to CRM)
-
0
A quirk of the update language is that when there are multiple updates that reference indexes in the same array, the updates are ordered by the lexicographic order of the indexes, rather than numerical order. For example, when updating indexes 2 and 10 the update to 10 applies first.
We noted this behavior in SERVER-31821, but we did not realize at the time that there are updates that would succeed if applied in ascending numerical order but fail because they are applied in lexicographic order.
Consider the update:
{$inc: {"array.2": 1, "array.10": 1}}
If "array" is initially empty, the update applies to "array.10" first, which creates an entry at slot 10 and extends the array with "null" for slots 0-9. The update for "array.2" then gets applied to a null value, causing it to fail. If these updates had been applied in the opposite order (numerically ascending), both would have succeeded.
- duplicates
-
SERVER-50778 "Cannot apply $bit" when $bit update grows an array
- Closed
- is duplicated by
-
SERVER-35220 Updating a document with dotted notation failed with PathNotViable if array is sufficiently large
- Closed
- related to
-
SERVER-88807 Field order for numeric paths in embedded documents is inconsistent when $set replicates between 4.4 and 5.0
- Open
-
SERVER-31821 Update operator $min handles non-existent array elements differently in 3.6
- Closed