我在功能测试期间设置和拆除了我的MongoDB数据库。
我的一个模型将使用GridFS，我将运行该测试（也称为setup和teardown）。假设我们从一个名为test_repoapi的干净空数据库开始：
python serve.py testing.ini 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。
对此有何想法？
答案 0 :(得分：0)
我们曾经遇到类似的问题，mongoengine在测试期间无法在drop_collection()之后重新创建索引，因为它未能实现丢弃收集也会丢弃索引。但这种情况发生在正常的集合和一个相当古老的mongoengine版本（以及QuerySet._reset_already_indexed()的调用为我们修复它 - 但是我们从0.6开始就不需要它了）
也许这是mongoengine在内部跟踪已经创建了哪些索引的另一种情况，它只是没有意识到数据库/集合已经消失并且必须重新创建这些索引？在测试之间使用drop_collection()的FWIW正在为我们工作，其中包括GridFS。