为什么django会检查settings.DATABASE NAME db是否实际存在以运行测试用例？

Question

我会经常为我的django项目运行测试用例。但是一个 好日子，我发现django实际检查了 settings.DATABASE_NAME db运行测试用例时实际存在。 为什么会如此。我只想到django将采取的 settings.DATABASE_NAME并创建一个名为'test_'+的测试数据库 settings.DATABASE_NAME。它还检查数据库是否与 name = settings.DATABASE_NAME，实际上是否存在（for 创建测试数据库）？理想情况下，只应检查名称 但不是db的实际存在吗？

我浏览了django源代码，发现用于创建testdb的“连接”实际上是使用DATABASE设置选项创建的。所有这一切都应该被设置的价值而不是它们的实际存在所困扰。正确？

Answer 1

整洁的问题......你知道，这从未发生在我身上。简短的回答是Django本身并不需要来验证DATABASE_NAME实际存在，但它确实需要连接到数据库才能创建测试数据库。大多数数据库接受（并且需要）DATABASE_NAME以便制定连接字符串;通常这是因为您要连接的数据库名称有助于您的连接会话的权限。

由于测试数据库尚不存在，因此django必须先使用普通settings.DATABASE_NAME进行连接才能创建测试数据库。

所以，它的工作原理如下：

• Django的测试运行器传递给特定于后端的数据库处理程序
• 特定于后端的数据库处理程序有一个名为create_test_db的函数，它将使用常规设置连接到数据库。它使用普通cursor = self.connection.cursor()命令执行此操作，该命令显然使用了正常设置值，因为此时它就知道存在的所有值。
• 连接到数据库后，特定于后端的处理程序将发出一个CREATE DATABASE命令，其中包含新测试数据库的名称。
• 特定于后端的处理程序关闭连接，然后返回到测试运行器，该测试运行器交换test_database_name的正常settings.DATABASE_NAME
• 然后测试将正常运行。对connection.cursor()的所有后续调用都将使用正常设置模块，但现在该模块具有换出的数据库名称
• 最后，测试运行器在调用后端特定处理程序的destroy_test_db函数后恢复旧数据库名称。

如果您有兴趣，主要部分的相关代码在django.db.backends.creation中。看看_create_test_db函数。

我认为Django设计者有可能在db-by-db的基础上创建异常，因为不是每个DB都需要连接字符串中的当前数据库名称，但这需要一些重构。现在，create_test_db函数实际上位于backend基类中的一个，并且大多数实际的后端处理程序不会覆盖它，因此有相当数量的代码可以推送到下游并复制到每个后端。