[SERVER-13001] exclude nModified from legacy write results Created: 03/Mar/14  Updated: 11/Jul/16  Resolved: 19/Mar/14

Status: Closed
Project: Core Server
Component/s: Sharding, Shell, Write Ops
Affects Version/s: None
Fix Version/s: 2.6.0-rc2

Type: Bug Priority: Major - P3
Reporter: A. Jesse Jiryu Davis Assignee: Scott Hernandez (Inactive)
Resolution: Done Votes: 0
Labels: 26qa
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
is duplicated by SERVER-13093 mongos update command implementation ... Closed
Related
related to SERVER-13210 nModified should be 0 when a write er... Closed
is related to DRIVERS-144 nModified should be null from legacy ... Closed
is related to DRIVERS-145 Don't include the nModified field in ... Closed
Backwards Compatibility: Fully Compatible
Operating System: ALL
Steps To Reproduce:

With the 2.6 shell connected to a 2.4 server:

repl0:PRIMARY> db.serverBuildInfo().version
2.4.9
repl0:PRIMARY> db.coll.drop()
true
repl0:PRIMARY> db.coll.insert([{_id: 1}])
Cannot use commands write mode, degrading to compatability mode
WriteResult({ "nInserted" : 1 })
repl0:PRIMARY> var bulk = db.coll.initializeOrderedBulkOp()
repl0:PRIMARY> bulk.find({_id: 1}).update({$set: {x: 1}})
repl0:PRIMARY> bulk.execute()
BulkWriteResult({
    "writeErrors" : [ ],
    "writeConcernErrors" : [ ],
    "nInserted" : 0,
    "nUpserted" : 0,
    "nMatched" : 1,
    "nModified" : 0,
    "nRemoved" : 0,
    "upserted" : [ ]
})

Participants:

 Description   

If nModified cannot be returned, like with a legacy write using GLE, then it should be excluded to indicate it is not valid. This is true in both the shell, and server (including mongos).



 Comments   
Comment by Githook User [ 19/Mar/14 ]

Author:

{u'username': u'scotthernandez', u'name': u'Scott Hernandez', u'email': u'scotthernandez@gmail.com'}

Message: SERVER-13001: fixup mongos side with mixed version shards

(cherry picked from commit 971bbb28a0c25ae26abe9da38e2b02b4cac36d9b)
Branch: v2.6
https://github.com/mongodb/mongo/commit/1c5e4d72d290388f2d1cb7e60c9f1e63aa24893c

Comment by Githook User [ 19/Mar/14 ]

Author:

{u'username': u'scotthernandez', u'name': u'Scott Hernandez', u'email': u'scotthernandez@gmail.com'}

Message: SERVER-13001: fixup mongos side with mixed version shards
Branch: master
https://github.com/mongodb/mongo/commit/971bbb28a0c25ae26abe9da38e2b02b4cac36d9b

Comment by Githook User [ 13/Mar/14 ]

Author:

{u'username': u'scotthernandez', u'name': u'Scott Hernandez', u'email': u'scotthernandez@gmail.com'}

Message: SERVER-13001: exclude nModified from legacy write results
Branch: v2.6
https://github.com/mongodb/mongo/commit/45f2cf47ea042c573995854a095f791c342d3307

Comment by Githook User [ 13/Mar/14 ]

Author:

{u'username': u'scotthernandez', u'name': u'Scott Hernandez', u'email': u'scotthernandez@gmail.com'}

Message: SERVER-13001: exclude nModified from legacy write results
Branch: master
https://github.com/mongodb/mongo/commit/4c1db9421bd72fdac754ae007e6197b42d9ed5c6

Comment by A. Jesse Jiryu Davis [ 10/Mar/14 ]

The shell's Bulk API implementation, when using write commands, will need to do something like:

full_result = {                
    "writeErrors": [],         
    "writeConcernErrors": [],  
    "nInserted": 0,            
    "nUpserted": 0,            
    "nMatched": 0,             
    "nModified": 0,            
    "nRemoved": 0,             
    "upserted": [],            
}                              
 
for each server response in all bulk operations' responses:
    if the operation is an update:
        if the response has a non-NULL nModified:
            if full_result has a non-NULL nModified:
                full_result['nModified'] += response['nModified']
        else:
            # If any call does not return nModified we can't report
            # a valid final count so omit the field completely.
            remove nModified from full_result or set to NULL

Comment by Scott Hernandez (Inactive) [ 10/Mar/14 ]

Correct, a client (mongos likewise) cannot aggregate numbers and non-numbers like you describe.

Comment by A. Jesse Jiryu Davis [ 10/Mar/14 ]

Clarifying a detail: I think that if an update applies to multiple shards and some are 2.6, some are 2.4, mongos must not return nModified, because mongos doesn't know nModified's true value.

The general policy is: "nModified is 0 if you know it's 0. It's N if you know it's N. It's omitted (or NULL) if you don't know its true value."

Comment by Scott Hernandez (Inactive) [ 07/Mar/14 ]

It depends on the code refactoring but hoping for omission of the field if not available. We will note well in the issue when we have a solution, and include the actual output from the commands and (bulk api) shell response.

Comment by A. Jesse Jiryu Davis [ 07/Mar/14 ]

Is the plan for mongos to omit nModified from the response document, or to set it to NULL? Drivers should know which to expect.

Comment by Eliot Horowitz (Inactive) [ 03/Mar/14 ]

It has to set it to NULL, cannot be 0 or nMatched as those are both incorrect.

Comment by Scott Hernandez (Inactive) [ 03/Mar/14 ]

This is by design and the docs need to updated: DOCS-2838

nModified means something different than matched and it is incorrect to report it way you suggest.

Generated at Thu Feb 08 03:30:19 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.