Description
When connected to a legacy (pre-2.6) version of MongoDB, the Bulk API will raise OperationFailure if the server response includes a jnote or wnote field. This was done to mimic the error a 2.6 standalone returns if a write concern with w > 1 is used or a mongo cluster returns if j=True is used with journaling disabled.
Unfortunately, the server will also return wnote if the write concern was not satisfied because no write operations were performed (e.g. an update or remove operation that didn't match any documents).
>>> bulk = c.foo.bar.initialize_ordered_bulk_op()
|
>>> bulk.find({"something": "that doesn't exist"}).remove()
|
>>> bulk.execute({'w': 2})
|
Traceback (most recent call last):
|
File "<stdin>", line 1, in <module>
|
File "pymongo/bulk.py", line 585, in execute
|
return self.__bulk.execute(write_concern)
|
File "pymongo/bulk.py", line 433, in execute
|
return self.execute_legacy(generator, write_concern)
|
File "pymongo/bulk.py", line 394, in execute_legacy
|
_merge_legacy(run, full_result, exc.details, idx)
|
File "pymongo/bulk.py", line 93, in _merge_legacy
|
raise OperationFailure(note, _BAD_VALUE, result)
|
pymongo.errors.OperationFailure: no write has been done on this connection
|
>>> c.server_info()['version']
|
u'2.4.10'
|
The impact of this bug should be limited by a few factors:
- This error is only raised by the Bulk API, not collection.insert/update/remove
- In PyMongo the execute method has to be called with a custom write concern with w > 1. No error is raised when using the default write acknowledgement or w=1.
- The bug only manifests with server versions before 2.6. The bulk API is only really useful from a performance perspective when connected to MongoDB 2.6 or newer.