Better nModified handling PYTHON-647

In a sharded cluster with mixed version shards (i.e.
one shard primary is 2.6, another is 2.4 or older) the
result of one call to update could include nModified
when the next does not. Since there is no way to provide
a valid count in this case we omit the field. Make sure
you upgrade your entire cluster to MongoDB 2.6 or newer
before relying on this field.

Author: behackett

doc/examples/bulk.rst

@@ -84,8 +84,9 @@ describing the type and count of operations performed.
   >>>
 
 .. warning:: ``nModified`` is only reported by MongoDB 2.6 and later. When
-  connected to an earlier server version, PyMongo omits this field from the
-  results of a bulk write operation.
+  connected to an earlier server version, or in certain mixed version sharding
+  configurations, PyMongo omits this field from the results of a bulk
+  write operation.
 
 The first write failure that occurs (e.g. duplicate key error) aborts the
 remaining operations, and PyMongo raises

pymongo/bulk.py

@@ -152,7 +152,15 @@ def _merge_command(run, full_result, results):
                 full_result["nMatched"] += (affected - n_upserted)
             else:
                 full_result["nMatched"] += affected
-            full_result["nModified"] += result.get("nModified", 0)
+            n_modified = result.get("nModified")
+            # SERVER-13001 - in a mixed sharded cluster a call to
+            # update could return nModified (>= 2.6) or not (<= 2.4).
+            # If any call does not return nModified we can't report
+            # a valid final count so omit the field completely.
+            if n_modified is not None and "nModified" in full_result:
+                full_result["nModified"] += n_modified
+            else:
+                full_result.pop("nModified", None)
 
         write_errors = result.get("writeErrors")
         if write_errors: