[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: |
|
||||||||
| 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:
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: | |||||||||||||||
| 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: | |||||||||||||||
| Comment by Siyuan Zhou [ 14/Oct/15 ] | |||||||||||||||
|
jstests/core/constructors.js failed again. | |||||||||||||||
| Comment by Max Hirschhorn [ 13/Oct/15 ] | |||||||||||||||
|
With the changes from
and found that the following set of tests fail when run against a mongos where the "test" database doesn't exist:
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:
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. |