Info
After setting FCV to 3.6 on 3.5.12, the mongo shell session appears as from the repro. This is different from FCV 3.4, which would give the following response:
WriteResult({
"nMatched" : 0,
"nUpserted" : 0,
"nModified" : 0,
"writeError" : {
"code" : 16837,
"errmsg" : "cannot use the part (a of a.b) to traverse the element ({a: 1.0})"
}
})
In the example, field 'a' can actually be nearly any data type including a number, a string, an array, NaN, null, or undefined. This difference can also be observed regardless of whether multi or upsert is set to true / false. FCV 3.6 would return nMatched as the number of documents matching the portion of the query.
The WriteResult given in FCV 3.6 may not accurately reflect a reason (or reflect a reason at all) for why no documents were upserted / modified, especially when upsert is set to true.
Top User Comments
ian@10gen.com commented on Tue, 5 Sep 2017 14:51:43 +0000:
Per Tess' comment above this was a bug in 3.4 which was fixed in 3.6 and we are not backporting the fix to 3.4.
tess.avitabile commented on Fri, 25 Aug 2017 15:44:26 +0000:
This is a bug on 3.4 and 3.6 featureCompatibilityVersion 3.4. We call prepare() on the ModifierInterface for $setOnInsert even in an update context, when we will not apply it. Then if there is a blocking element and the $setOnInsert cannot be applied, we return an error, even though we were not going to apply the $setOnInsert. On 3.4. On 3.6 featureCompatibilityVersion 3.4.
Steps to Reproduce
FCV 3.6:
> db.fuzzer.insert({'a': 1 })
WriteResult({ "nInserted" : 1 })
> db.fuzzer.update({}, {$setOnInsert: {'a.b': 2 }})
WriteResult({ "nMatched" : 1, "nUpserted" : 0, "nModified" : 0 })
