database - 为什么 django 检查 settings.DATABASE_NAME db 是否实际存在以运行测试用例？

Question

我会经常为我的 Django 项目运行测试用例。但是一个美好的一天，我突然想到 django 实际上会检查settings.DATABASE_NAME db 在运行测试用例时实际存在。为什么会这样。我以为 django 会接受settings.DATABASE_NAME 并创建一个名为“test_”的测试数据库 +设置.DATABASE_NAME。它还检查数据库是否与name = settings.DATABASE_NAME，实际存在与否(for创建测试数据库)？理想情况下，只应检查名称但不是数据库的实际存在吗？

我浏览了 django 源代码，发现用于创建 testdb 的“连接”实际上是使用 DATABASE 设置选项创建的。它应该为设置的值而不是它们的实际存在而烦恼。对吧？

Answer 1

好问题……你知道，我从来没有想过这个问题。简短的回答是 Django 本身并不需要验证 DATABASE_NAME 确实存在，但它确实需要连接到数据库以创建测试数据库。大多数数据库接受(有些需要)DATABASE_NAME 以制定连接字符串；这通常是因为您要连接的数据库名称影响了您的连接 session 的权限。

因为测试数据库还不存在，django 必须首先使用正常设置连接。DATABASE_NAME 以创建测试数据库。

所以，它是这样工作的:

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

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

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