Details
-
Task
-
Resolution: Fixed
-
Major - P3
-
None
-
None
Description
In MongoDB 3.6, when the featureCompatibilityVersion is 3.6, we use our new update system implementation, which supports arrayFilters. This system has some minor behavior differences from 3.4 that may be worth documenting in the release notes:
- Conflict detection is done at parse time, rather than update time. For example, in 3.4, the update
db.c.update({_id: 0}, {$set: {a: 0}, $unset: {a: true}})only fails if there is a document with _id=0, but this always fails in 3.6. In 3.4, the update
db.c.update({_id: 0}, {$set: {a: 0}, $setOnInsert: {a: 1}}, {upsert: true})only fails if there is no document with _id=0 (so a document is inserted), but this always fails in 3.6.
- New fields are added in lexicographic order, rather than the order they appear in the update statement. For example, in 3.4, the update
db.c.update({_id: 0}, {$set: {b: 0, a: 0}})updates the document {_id: 0} to {_id: 0, b: 0, a: 0}. In 3.6, the document will be updated to {_id: 0, a: 0, b: 0}. (Note that since featureCompatibilityVersion is used to gate the new update system, you cannot end up with different field orderings for the document on different members of the replica set.)
- The array filter identifier syntax is treated as an array update, rather than a fieldname. For example, in 3.4, the update
db.c.update({_id: 0}, {$unset: {"a.$[]": true}})updates the document {_id: 0, a: {"$[]": 1}} to {_id: 0}. In 3.6, the update fails because a is not an array.
- It is illegal to remove a required part of a DBRef using $unset or $rename. See
SERVER-29819.
I will leave it to the discretion of the docs team which behavior changes are worth documenting. If you have any concerns about a backwards-breaking change, or any questions, feel free to reach out.