[SERVER-20852] db.eval should not implicitly create a database when talking to mongod Created: 09/Oct/15  Updated: 06/Dec/22  Resolved: 01/Oct/19

Status: Closed
Project: Core Server
Component/s: JavaScript
Affects Version/s: 3.1.9
Fix Version/s: None

Type: Improvement Priority: Minor - P4
Reporter: Charlie Swanson Assignee: DO NOT USE - Backlog - Dev Tools
Resolution: Done Votes: 0
Labels: disabled-test
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
is depended on by SERVER-20414 Configure Evergreen to run more suite... Closed
Assigned Teams:
Developer Tools
Sprint: Sharding 2016-08-29
Participants:

 Description   

Running the eval command on a mongos will not implicitly create the database, while running it on a mongod will. These two behaviors should be consistent. If the database doesn't exist, the command should always create it, or never create it, regardless of whether it's talking to a mongos or a mongod.

Because mongos cannot create a representation of the database without writing durable data, the behavior of mongod should be changed to match that of mongos.

This behavior was noticed while running a patch build using the --shuffle option to resmoke.py, eval7.js failed during the sharded_collections_jscore_passthrough suite with the following message:

[js_test:eval7] 2015-10-09T03:32:13.811+0000 2015-10-09T03:32:13.811+0000 E QUERY    [thread1] Error: { "ok" : 0, "errmsg" : "database test not found", "code" : 26 } :
[js_test:eval7] 2015-10-09T03:32:13.811+0000 _getErrorWithCode@src/mongo/shell/utils.js:23:13
[js_test:eval7] 2015-10-09T03:32:13.811+0000 DB.prototype.eval@src/mongo/shell/db.js:553:1
[js_test:eval7] 2015-10-09T03:32:13.811+0000 @jstests/core/eval7.js:2:16

This normally doesn't fail, as it usually isn't the first test to run, and the database will already exist by then.



 Comments   
Comment by Spencer Jackson [ 01/Oct/19 ]

db.eval has been removed.

Comment by Andy Schwerin [ 07/Sep/16 ]

I have fixed the existing tests to ensure the database exists before running db.eval. It remains to actually make mongod error like mongos does when the database does not exist.

Comment by Githook User [ 07/Sep/16 ]

Author:

{u'username': u'andy10gen', u'name': u'Andy Schwerin', u'email': u'schwerin@mongodb.com'}

Message: SERVER-20852 Ensure that js tests of db.eval create the db before calling eval on it.
Branch: master
https://github.com/mongodb/mongo/commit/1f9ece1185c7e40aabe96d8e5dc5a79fea3808f3

Comment by Andy Schwerin [ 26/Aug/16 ]

As it turns out, mongod doesn't really create the database on disk as a result of the db.eval, only the in-memory representation. Unfortunately, mongos is not allowed to take such half-measures. It must either affirmatively create the database, creating an entry for it in config.databases, or it must reject the command.

I believe we should change the behavior of mongod to reject the command just as mongos does, and then update the handful of tests identified above.

Comment by Githook User [ 14/Oct/15 ]

Author:

{u'username': u'kkmongo', u'name': u'Kamran Khan', u'email': u'kamran.khan@mongodb.com'}

Message: SERVER-20852 Disable tests that assume a database is implicitly created
Branch: master
https://github.com/mongodb/mongo/commit/fe9e2a544e62863c4bba5dc660721f98b09addeb

Comment by Siyuan Zhou [ 14/Oct/15 ]

jstests/core/constructors.js failed again.

Comment by Max Hirschhorn [ 13/Oct/15 ]

With the changes from SERVER-20899 and the following patch, I ran

python buildscripts/resmoke.py --suites sharded_collections_jscore_passthrough --continueOnFailure

and found that the following set of tests fail when run against a mongos where the "test" database doesn't exist:

  • jstests/core/constructors.js
  • jstests/core/eval0.js
  • jstests/core/eval7.js
  • jstests/core/eval9.js

diff --git a/buildscripts/resmokeconfig/suites/sharded_collections_jscore_passthrough.yml b/buildscripts/resmokeconfig/suites/sharded_collections_jscore_passthrough.yml
index 1fef054..4945ab9 100644
--- a/buildscripts/resmokeconfig/suites/sharded_collections_jscore_passthrough.yml
+++ b/buildscripts/resmokeconfig/suites/sharded_collections_jscore_passthrough.yml
@@ -66,6 +66,9 @@ executor:
       shell_options:
         readMode: commands
         eval: load("jstests/libs/override_methods/implicitly_shard_accessed_collections.js")
+    hooks:
+    - class: CleanEveryN
+      n: 1
     fixture:
       class: ShardedClusterFixture
       mongos_options:

Propose blacklisting these tests from the passthrough until the underlying issue is fixed. CC kamran.khan

Comment by Max Hirschhorn [ 12/Oct/15 ]

Failed while running jstests/core/constructors.js under the sharded_collections_jscore_passthrough suite:

[js_test:constructors] 2015-10-11T22:04:06.462+0000 WARNING: db.eval is deprecated
[js_test:constructors] 2015-10-11T22:04:06.464+0000 2015-10-11T22:04:06.463+0000 E QUERY    [thread1] uncaught exception: valid constructor: DBRef("namespace", 0) failed in db.eval context: Error: { "ok" : 0, "errmsg" : "database test not found", "code" : 26 }

These tests do not fail under the sharding_jscore_passthrough suite because the enableSharding command will create an entry in the catalog for the "test" database.

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