问题描述
我继承了一个完善的基于烧瓶的 API 服务，该服务广泛使用了 mongoengine。我们正在将这个单数据库 API 变成一个多租户服务，并且不清楚最佳实践。出于多种原因，租户数据将被物理隔离到不同的数据库中，每个租户一个 db。 （对于某些文档，还有一个到“核心”数据库的连接。）
用例工作流程很简单：
似乎实现这一点的最佳方法是使用别名，但是当我进行上下文切换时，我需要 disconnect('tenant_db') 然后 connect(alias='tenant_db')。这感觉不对。
无论如何，代码确实有效，但现在我遇到了单元测试问题。在测试和使用（每个文档）mongomock://localhost 连接时，代码实际上在尝试连接到在本地主机上运行的真实 mongodb 时超时。我怀疑所有这些都与没有适当范围的模拟连接有关，但我找不到关于使用模拟数据库进行测试的太多文档。
抱歉，两个问题合二为一：
不是 pytest 的专业人士，也不是新手。与 pymongo 一致，但对 mongoengine 全新。
谢谢！
解决方法
没有得到 mongoengine 社区的任何回应有点失望 - 也许它没有我希望的那么活跃。
以下是进一步调查的结果，以及我们决定的方法。
第一个尖峰 - 单个 tenant_db 别名，并在每个请求上更改底层连接。优点：这允许现有代码无需太多重构即可工作。缺点：如果没有 disconnect 和 reconnect，就不可能更改已注册连接的详细信息，并且会触发有关默认数据库的警告（没有“默认”，这是每个请求，但“默认”是需要。）这很混乱，没有成功。
第二个尖峰 - 咬紧牙关，将每个 Document 实例化重构为 with switch_db(alias) 模式，为每个租户使用唯一别名。优点：这种明确的性质使文档操作将在正确的数据库中发生更有信心。 Pro #2，关于“默认”数据库的不断警告实际上对我们有利——任何不在 switch_db 上下文中的流氓文档操作都会抛出错误。缺点：在 disconnect 上下文之前仍然需要 reconnect 和 with。
第三次峰值 - 我们考虑分叉 mongoengine，并将 Document 类更改为更纯 - 允许注入 db 连接，而不是依赖外部注册连接堆栈。优点：我们可以完全控制数据库连接逻辑。缺点：db 的东西深深植根于 mongoengine 的 DNA - 如果不付出大量努力，这看起来不太可能成功。
我们选择了 Spike 2。
由于 gunicorn->wsgi->flask 为我们提供了可靠的 _per-request 隔离，并且租户的新“默认”连接发生在请求身份验证成功后，因此利用 with switch_db(alias) 有效。这使我们能够进行短期修复，使这个单租户代码库以多租户方式运行。
我们也不是 100% 确信我们了解基础 pymongo 将如何连接池以提高性能。在那里做更多的学习。
最后，关于 pytest 的混淆。在 Spike One 中，由于设备、范围、断开/重新连接等原因，不可能使用模拟进行测试。 Spike Two 效果更好，除了我们必须在实际代码中添加一个环境变量，这样它就不会尝试建立真正的连接，如果我们处于“unit_test_mode”。