Details
-
Improvement
-
Resolution: Done
-
Major - P3
-
None
-
None
-
Fully Compatible
-
TIG 2017-02-13, TIG 2017-03-06, TIG 2017-03-27
-
0
Description
Our tests in the jstests/core/ directory tend to take one of the following two forms.
// DB.prototype.getCollection() is called before DBCollection.prototype.drop(), and the local
|
// variable is used when inserting a document into the collection.
|
var coll = db.mycoll_var; |
coll.drop();
|
assert.writeOK(coll.insert({}));
|
|
|
// DB.prototype.getCollection() is called before DBCollection.prototype.drop(), and the cached
|
// DBCollection object is used when inserting a document into the collection.
|
db.mycoll_novar.drop();
|
assert.writeOK(db.mycoll_novar.insert({}));
|
Tests drop the collection that they act as one of their first operations so that they may be re-run without having to clear the data directory. This poses an issue for the current implementation of the sharded_collections_jscore_passthrough suite because the test will proceed with the collection not being sharded after the collection has been dropped. We should consider overriding DBCollection.prototype.drop() (or the Mongo.prototype.runCommand() equivalent) in implicitly_shard_accessed_collections.js to gain coverage in running a variety of operations against a sharded collection.
Note: the value previously returned by the DB.prototype.getCollection() is cached, the DB.prototype.getCollection() function will not be called a second time.
Attachments
Issue Links
- is related to
-
SERVER-20289 Create a sharding passthrough that implicitly shards collections
-
- Closed
-
- related to
-
SERVER-28321 In mapReduce map function emitting a document with 'undefined' or 'null' key in sharded collection fails
-
- Closed
-
-
SERVER-28500 Implicitly sharding dropped collection can fail if test is running with parallel shell
-
- Closed
-