Launching soon: The world's first vendor agnostic bug scrubLearn more & join waitlist
OPERATIONAL DEFECT DATABASE
...
...
Running eval on an empty database on mongos returns an error on MongoDB 3.2.8 (and 3.3.10), but not on 3.0.12. On 3.0.12: mongos> db.serverStatus().version 3.0.12 mongos> db.dropDatabase() { "dropped" : "test", "ok" : 1 } mongos> db.runCommand({eval:function(){return 42}}) { "retval" : 42, "ok" : 1 } On 3.2.8: MongoDB Enterprise mongos> db.serverStatus().version 3.2.8 MongoDB Enterprise mongos> db.dropDatabase() { "info" : "database does not exist", "ok" : 1 } MongoDB Enterprise mongos> db.runCommand({eval:function(){return 42}}) { "ok" : 0, "errmsg" : "database test not found", "code" : 26 } On 3.3.10: MongoDB Enterprise mongos> db.serverStatus().version 3.3.10 MongoDB Enterprise mongos> db.dropDatabase() { "info" : "database does not exist", "ok" : 1 } MongoDB Enterprise mongos> db.runCommand({eval:function(){return 42}}) { "ok" : 0, "errmsg" : "database test not found", "code" : 26 }
kaloian.manassiev commented on Wed, 17 Aug 2016 13:20:36 +0000: Generally, we have been striving towards parity between mongod and mongos. In the case of eval though the problem is the there is no JS parser on mongos as it only serves as a router, so it has no way of knowing what the script is doing in order to behave the same as mongod. Given that eval is on its way to getting deprecated we have no plans on closing that parity gap so I am closing this ticket with "Works As Designed". david.golden commented on Wed, 17 Aug 2016 03:25:01 +0000: If the design is that implicit database creation is a "bad thing" in some cases, then I'd like to see that behavior be the same between mongod and mongos. That said, given the design, I don't understand the rationale. Assuming the user is authenticated to write to a DB, why can one write to a collection in the database and have both spring into existence ("good thing"), but some other operations fail if the database doesn't exist ("bad thing")? That inconsistency seems odd. kaloian.manassiev commented on Wed, 17 Aug 2016 01:03:49 +0000: The reason for the change in behaviour is described in the linked SERVER-17917. Basically, mongos simply forwards the eval command to the primary shard for the database against which it is run. Since the database does not exist, it doesn't know where to forward it and simply fails. This didn't use to be the case before 3.2 where every operation against an unknown database would create it.
1. Launch 3.2 sharded cluster 2. Connect via shell 3. Drop database 4. Run eval command