[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:
Related
related to SERVER-31894 Update operator $max with multiple fi... Closed
is related to SERVER-33687 Sort order of array indexes can deter... Closed
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.

db.test.insert({"_id": "unique", "a": [],});
db.test.update({}, {"$min": {"a.1": {"x": 1}, "a.0": {"y": 1, }}});
 
// 3.6: {  "_id" : "unique",  "a" : [ { "y" : 1 }, { "x" : 1 } ] }
// 3.4 and prior: {  "_id" : "unique",  "a" : [ null, { "x" : 1 } ] }



 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.

Generated at Thu Feb 08 04:28:17 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.