[SERVER-26315] sharded_collections_jscore_passthrough should re-shard the collection after the test drops it Created: 26/Sep/16  Updated: 05/Apr/17  Resolved: 23/Mar/17

Status: Closed
Project: Core Server
Component/s: Testing Infrastructure
Affects Version/s: None
Fix Version/s: 3.5.5

Type: Improvement Priority: Major - P3
Reporter: Max Hirschhorn Assignee: Eddie Louie
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
related to SERVER-28321 In mapReduce map function emitting a ... Closed
related to SERVER-28500 Implicitly sharding dropped collectio... Closed
is related to SERVER-20289 Create a sharding passthrough that im... Closed
Backwards Compatibility: Fully Compatible
Sprint: TIG 2017-02-13, TIG 2017-03-06, TIG 2017-03-27
Participants:
Linked BF Score: 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.



 Comments   
Comment by Githook User [ 24/Mar/17 ]

Author:

{u'username': u'elouie99', u'name': u'Eddie Louie', u'email': u'eddie.louie@mongodb.com'}

Message: SERVER-26315 Modify comments for blacklisted mr_undef.js file to refer to
correct SERVER ticket
Branch: master
https://github.com/mongodb/mongo/commit/755a2bcd0fe08a4b521c2f544e887fcfef0d1220

Comment by Githook User [ 23/Mar/17 ]

Author:

{u'username': u'elouie99', u'name': u'Eddie Louie', u'email': u'eddie.louie@mongodb.com'}

Message: SERVER-26315 Override DBCollection.prototype.drop to re-shard collections that are dropped

This reverts commit fb956b3b0a48c9b8376575c6adb971a4e0593292.
Branch: master
https://github.com/mongodb/mongo/commit/9fc1ecd711851cccee04fe14caf88db0c6523090

Comment by Githook User [ 23/Mar/17 ]

Author:

{u'username': u'renctan', u'name': u'Randolph Tan', u'email': u'randolph@10gen.com'}

Message: Revert "SERVER-26315 Override DBCollection.prototype.drop to re-shard collections that are dropped"

This reverts commit 56e66454d14e16689331672734ecde7644a41c78.

Conflicts:
buildscripts/resmokeconfig/suites/sharded_collections_jscore_passthrough.yml
Branch: master
https://github.com/mongodb/mongo/commit/fb956b3b0a48c9b8376575c6adb971a4e0593292

Comment by Githook User [ 15/Mar/17 ]

Author:

{u'username': u'elouie99', u'name': u'Eddie Louie', u'email': u'eddie.louie@mongodb.com'}

Message: SERVER-26315 Override DBCollection.prototype.drop to re-shard collections that are dropped
in sharded cluster environments.
Branch: master
https://github.com/mongodb/mongo/commit/56e66454d14e16689331672734ecde7644a41c78

Comment by Eddie Louie [ 15/Mar/17 ]

Just a note that in addition to the sharded_collections_jscore_passthrough suite, we needed to scrub the aggregation_sharded_collections_passthrough suite.

Comment by Eddie Louie [ 17/Feb/17 ]

Here is the Evergreen patch

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