Uploaded image for project: 'Core Server'
  1. Core Server
  2. SERVER-26315

sharded_collections_jscore_passthrough should re-shard the collection after the test drops it

    XMLWordPrintable

    Details

    • Type: Improvement
    • Status: Closed
    • Priority: Major - P3
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 3.5.5
    • Component/s: Testing Infrastructure
    • Labels:
      None
    • Backwards Compatibility:
      Fully Compatible
    • Sprint:
      TIG 2017-02-13, TIG 2017-03-06, TIG 2017-03-27
    • 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.

        Attachments

          Issue Links

            Activity

              People

              • Votes:
                0 Vote for this issue
                Watchers:
                5 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: