we have a large collection with a shard key on _id.c, example
{_id : {"a":"foo","b":1234,"c":3456}
. When performing upserts we found that passing a query of _id alone resulted in the query being broadcast. to address this waste of work (waste for all but 1 shard), we changed the query of the upsert to
{"_id":{....},"_id.c":3456\}
. this did properly route the upsert to the appropriate shard. it appears that with this configuration, if a document already exists based on _id, the update works fine. when the document needs to be created, mongodb mistakenly injects two _id attributes into the new document. we will see exactly what was provided in the query:
{"_id":{"a":"foo","b":1234,"c":3456},"_id":{"c":3456},...}
This probably should not occur. a side effect is that any driver which parses this document will either take the first occurrence of the attribute or the last one. the PHP driver takes the last one, resulting in an incomplete _id value.
The mongo shell does not output these documents correctly because of SERVER-718 (duplicate fields just repeat the first).
{"_id":{"a":"foo","b":1234,"c":3456},"_id":{"a":"foo","b":1234,"c":3456},...}
- depends on
-
SERVER-4830 Reject upsert if would create duplicate field names
- Closed
- is related to
-
SERVER-5710 Update may result in doc without shard key
- Closed
-
SERVER-9074 Upsert fails with "cannot modify shard key" when not modifying shard key
- Closed
-
SERVER-11363 Update call causes mongod to crash
- Closed
- related to
-
SERVER-7379 Immutable shardkey becomes mutable
- Closed