[SERVER-23145] Shell sharding helpers should give feedback on success Created: 15/Mar/16  Updated: 21/Nov/16  Resolved: 01/Jun/16

Status: Closed
Project: Core Server
Component/s: Sharding, Shell
Affects Version/s: None
Fix Version/s: 3.2.9, 3.3.8

Type: Improvement Priority: Major - P3
Reporter: Kevin Pulo Assignee: Kevin Pulo
Resolution: Done Votes: 0
Labels: code-only
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
depends on SERVER-22449 Check for write errors when changing ... Closed
Related
is related to SERVER-24335 Shell sharding helpers should use wti... Closed
Backwards Compatibility: Fully Compatible
Backport Completed:
Sprint: Sharding 15 (06/03/16)
Participants:

 Description   

SERVER-22449 means that failures in these functions will now correctly cause exceptions to be raised.

However, it is useful for users and support to receive positive feedback when the operations succeed.

This is so that success can be known immediately after the function has run, without needing to determine whether or not the user is running a post-SERVER-22449 version of the shell (ie. whether or not there would have been an exception).

For most of the sh.* functions, this just means adding return in front of the assert.writeOK. startBalancer and stopBalancer will likely be a little less straightforward.



 Comments   
Comment by Githook User [ 13/Jul/16 ]

Author:

{u'username': u'devkev', u'name': u'Kevin Pulo', u'email': u'kevin.pulo@mongodb.com'}

Message: SERVER-23145 SERVER-22449 sharding shell helpers return result and assert on failure

(cherry picked from commit a5864a5d54e667af548b4ce7b5b652ebcce84ef4)
Branch: v3.2
https://github.com/mongodb/mongo/commit/2cfe775137a32044b3831ea7f2ac7bea59f434e6

Comment by Githook User [ 01/Jun/16 ]

Author:

{u'username': u'devkev', u'name': u'Kevin Pulo', u'email': u'kevin.pulo@mongodb.com'}

Message: SERVER-23145 SERVER-22449 sharding shell helpers return result and assert on failure
Branch: master
https://github.com/mongodb/mongo/commit/a5864a5d54e667af548b4ce7b5b652ebcce84ef4

Comment by Spencer Brody (Inactive) [ 28/Apr/16 ]

Given that we do raise exceptions when something fails, it doesn't seem like returning something on success adds any information

Comment by Kevin Pulo [ 16/Mar/16 ]

The main motivation here is interactive use.

eg:

mongos> sh.setBalancerState(false)
mongos> 

vs

mongos> sh.setBalancerState = function( onOrNot ) {
...    return assert.writeOK(
...        sh._getConfigDB().settings.update(
...                                          { _id: "balancer" },
...                                          { $set : { stopped: onOrNot ? false : true } },
...                                          { writeConcern: { w: "majority"}, upsert: true} ));
... }
function ( onOrNot ) {
   return assert.writeOK(
       sh._getConfigDB().settings.update(
                                         { _id: "balancer" },
                                         { $set : { stopped: onOrNot ? false : true } },
                                         { writeConcern: { w: "majority"}, upsert: true} ));
}
mongos>
mongos> sh.setBalancerState(true)
WriteResult({ "nMatched" : 1, "nUpserted" : 0, "nModified" : 1 })
mongos> sh.setBalancerState(true)
WriteResult({ "nMatched" : 1, "nUpserted" : 0, "nModified" : 0 })
mongos>

Can you explain what you mean by "scripts", and why you think returning results isn't sufficient? If someone wants the result printed from inside a mongo shell script then they can just wrap printjson() or shellPrint() around it, same as anything else. Or they could assign it to a variable and then poke at it however they like (though they may also want to catch any exceptions).

Comment by Scott Hernandez (Inactive) [ 15/Mar/16 ]

Do you want to address scripts as well, or just REPL shell sessions? If so, returning results will not be sufficient.

I would propose that if you want positive feedback, or some status (output), then you simply do that and have any scripts print the state/status at the end. It is probably a better strategy across the boards anyway.

Generated at Thu Feb 08 04:02:31 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.