如果某些连接仍然存在，为什么在拆卸后不创建索引？

Question

我在功能测试期间设置和拆卸我的 MongoDB 数据库。

我的一个模型将使用 GridFS，我将运行该测试（也称为 setup 和 teardown）。假设我们从一个名为 test_repoapi 的干净空数据库开始：

1. python serve.py testing.ini
2. nosetests -a 'write-file'

第二次运行测试时，我得到了这个：

OperationFailure: command SON([('filemd5', ObjectId('518ec7d84b8aa41dec957d3c')), ('root', u'fs')]) failed: need an index on { files_id : 1 , n : 1 }

如果我们看客户：

> use test_repoapi
switched to db test_repoapi
> show collections
fs.chunks
system.indexes
users

这里是日志：http://pastebin.com/1adX4svG

时间戳分为三种：

(1) 顶部是我第一次启动网络应用时

(2) 23:06:27 之前的任何东西都是第一次迭代

(3) 然后一切都是第二次迭代

如您所见，我执行了删除数据库的初始化命令。两种可能的解释：

(1) Web 应用拥有两个到数据库的活动连接，并且

(2) 某种“锁”会阻止索引完全创建。还要看fs.files 没有重新创建。

解决方法是停止 Web 应用，重新启动，然后运行测试；那么错误将不会出现。

顺便说一句，我在我的网络应用程序中使用 Mongoengine 作为我的 ODM。

对此有什么想法吗？

Answer 1

我们曾经遇到过类似的问题，在测试期间 mongoengine 在drop_collection() 之后无法重新创建索引，因为它未能实现删除集合也会删除索引。但这发生在普通集合和相当古老的 mongoengine 版本中（并且调用 QuerySet._reset_already_indexed() 为我们修复了它 - 但我们从 0.6 开始就不需要它了）

也许这是 mongoengine 在内部跟踪已创建的索引的另一种情况，它只是未能意识到数据库/集合消失并且必须重新创建这些索引？在测试之间使用 drop_collection() 的 FWIW 对我们有用，其中包括 GridFS。