[SERVER-31821] Update operator $min handles non-existent array elements differently in 3.6 Created: 03/Nov/17 Updated: 27/Oct/23 Resolved: 03/Nov/17 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Querying |
| Affects Version/s: | 3.2.17, 3.4.10 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Robert Guo (Inactive) | Assignee: | Backlog - Query Team (Inactive) |
| Resolution: | Works as Designed | Votes: | 0 |
| Labels: | ufz | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||
| Assigned Teams: |
Query
|
||||||||||||
| Operating System: | ALL | ||||||||||||
| Participants: | |||||||||||||
| Description |
|
The `$min` update operator did not update certain non-existent array elements in 3.4 and 3.2, which is no longer the case in 3.6. The behavior under 3.6 seems to be the more correct one.
|
| Comments |
| Comment by Justin Seyster [ 03/Nov/17 ] |
|
That's an interesting behavior. Thanks for pointing it out! The update is actually behaving as designed in both cases. In 3.4, fields get updated in the order that they appear in the update document. The update to "a.1" extended the "a" array so that it looks like [null, {x: 1}]. The update to "a.0" then becomes a no-op, because null is considered less than {y: 1}. In 3.6, updates get ordered lexicographically by field name, so that "a.0" gets applied before the "a.1" update. Unfortunately, it is still possible in 3.6 to update two array fields out of order: e.g., an update to "a.10" will get applied before an update to "a.2" because indexes are ordered lexicographically rather than numerically. I'd still say this is behaving as intended, though. |