[DRIVERS-144] nModified should be null from legacy writes Created: 07/Mar/14  Updated: 15/Apr/19  Resolved: 04/Oct/16

Status: Closed
Project: Drivers
Component/s: None
Fix Version/s: None

Type: Task Priority: Major - P3
Reporter: Barrie Segal Assignee: Barrie Segal
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
depends on CXX-20 Implement full support for write comm... Closed
Related
related to SERVER-13001 exclude nModified from legacy write r... Closed
related to DRIVERS-143 Don't include the nModified field in ... Closed
is related to CXX-1172 Document `result::bulk_write::modifie... Closed
is related to PHPC-278 WriteResult::getModifiedCount() shoul... Closed
is related to CSHARP-925 nModified should be null from legacy ... Closed
is related to NODE-148 nModified should be null from legacy ... Closed
is related to PYTHON-648 nModified should be null from legacy ... Closed
is related to RUBY-727 nModified should be null from legacy ... Closed
Driver Compliance:
Key Status/Resolution FixVersion
CXX-20 Done legacy-0.9.0

 Description   

Related to DRIVERS-143, obviously. DRIVERS-143 is about the Bulk API's merged results from a series of operations.

This ticket is about the simple "update" operation. If a driver uses the new "update" command, the 2.6 server responds with an accurate count of documents actually changed, in the "nModified" field. For example, if a document has "x: 1" and you use the "update" command to set x to 1, the server responds with "nModified: 0".

This behavior is impossible to simulate with OP_UPDATE, so drivers shouldn't return an nModified field as the result of a legacy update operation. Depending on the language, the field should be absent, or NULL, or attempting to access it should raise an exception.



 Comments   
Comment by Andrew Morrow (Inactive) [ 03/Mar/15 ]

Validating for C+11 because validated for C, and C+11 does not itself do legacy writes.

Generated at Thu Feb 08 08:20:51 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.