Change collection.drop() to collection.deleteMany()

[bernardofd]

The collection.drop() method completely erases a collection from the database, including its indexes. It's better to only remove the documents but keep the indexes, since the user might use them in their tests. The method in mongodb-native v2.0 that allows just that is collection.deleteMany(). This is a correction of PR #31, since there is no removeMany() method on the collection API

[markstos]

I ran into test failures because of mixing indexes, so I agree something needs to be done to make sure that indexes continue to work after the fixture data is loaded.

[mingxinwei]

this is really useful, it should be merged

[powmedia]

What's an example of a situation where you want the indexes from a previous test? The indexes would be referring to documents that are no longer there, and in my experience for tests you want as clean a slate as possible each time.

[mingxinwei]

You could check this issue #37 .

In my practical unit test usage, when then indexes is droped also, its very easily to meet this error MongoError: cannot perform operation: a background operation is currently running for collection xxx. But after not deleting the index, i never encounter this error.

btw. Using deleteMany also speed up my unit test a lot.

What's an example of a situation where you want the indexes from a previous test? The indexes would be referring to documents that are no longer there, and in my experience for tests you want as clean a slate as possible each time.

[powmedia]

OK, however I think there must be another way of fixing the issue #37 without keeping the indexes around. One problem with not removing the indexes for example is if you are testing user account creation and you have a unique index on user.email - next time you run the tests you will get a duplicate key index error.

[markstos]

What's an example of a situation where you want the indexes from a previous test? The indexes would be referring to documents that are no longer there, and in my experience for tests you want as clean a slate as possible each time.

Mongo should be updating the index properly when documents are deleted, so the indexes should remain correct.

Code reasonably expects indexes to be present, not to manually create there. Without indexes, some operations will fail like some geo functions that require an index.

This package is going to drop indexes, it also needs restore them again.

[bernardofd]

My use case is a test suite where a field in the collection is expected to be unique. This is ensured by MongoDB through indexes, and the tests asserts the code behavior whenever MongoDB raise an error on insertion of a non-unique field. Each test starts with a `clearAllAndLoad()` call, so the Database status is the same for every test. If the indexes are reset, the test which expects the MongoDB error will fail. Bernardo Figuerêdo Domingues, Ph.D.

…

On Tue, Jun 27, 2017 at 10:53 AM, Mark Stosberg ***@***.***> wrote: What's an example of a situation where you want the indexes from a previous test? The indexes would be referring to documents that are no longer there, and in my experience for tests you want as clean a slate as possible each time. Mongo should be updating the index properly when documents are deleted, so the indexes should remain correct. Code reasonably expects indexes to be present, not to manually create there. Without indexes, some operations will fail like some geo functions that require an index. This package is going to drop indexes, it also needs restore them again. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#39 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACQZavqFRpZ81kMhQgSNKOJHOUPkSvBbks5sIQlbgaJpZM4L1kef> .

[powmedia]

Mongo should be updating the index properly when documents are deleted, so the indexes should remain correct.

Ah of course, OK will merge this PR