Differences in db.<collection>.drop() and db.<collection>.remove({})

XMLWordPrintableJSON

    • Type: Bug
    • Resolution: Done
    • Priority: Major - P3
    • None
    • Affects Version/s: 2.0.6
    • Component/s: Sharding, Shell
    • None
    • Environment:
      Mac OSX 10.7.4
      RHEL 6.1
    • OS X
    • None
    • None
    • None
    • None
    • None
    • None
    • None

      We have automated testing that loads data into a given state using mongoimport with json fixture data. To make sure the database is clean, we have been using --drop on mongo import which I believe to be equivalent to running db.<collection>.drop() prior to the mongoimport. However, now that we are testing against a sharded mongo deployment, we have changed the test code to do the following:

      sh "#

      {MONGO_BIN}mongo #{DB_HOST}/#{DB_NAME} --quiet --eval \"db.#{collectionName}.remove({})\""
      sh "#{MONGO_BIN}

      mongo #

      {DB_HOST}

      /#

      {DB_NAME}

      --quiet --eval \"db.adminCommand('flushRouterConfig')\""

      To preserve sharding between test runs. However, now we see intermittent failures on a piece of code that 'stamps' documents based on a given association algorithm and it is returning intermittent results. It seems that maybe db.<collection>.remove({}) is asynchronous or something like that. Maybe the algorithm is sensitive to order it gets data from a collection and that .remove({}) followed by an import makes the ordering of the data different?

      Also to note is that we see this behavior on non sharded mongo instances (when developers test on their local dev machine)

      I guess my goal of this JIRA (in the event it is working as designed) is to understand the fundamental differences between .drop() and .remove().

      Thanks

            Assignee:
            Unassigned
            Reporter:
            James Short
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated:
              Resolved: