Почему django проверяет, действительно ли существует база данных.DATABASE_NAME для запуска тестовых случаев?

Question

Я буду часто запускать тестовые сценарии для моего проекта django. Но один прекрасный день мне пришло в голову, что Джанго на самом деле проверяет settings.DATABASE_NAME db фактическое существование при выполнении тестовых случаев. Почему это так? Все, что я думал, что Джанго будет принимать settings.DATABASE_NAME и создает тестовую базу данных с именем 'test_' + settings.DATABASE_NAME. Он также проверяет, является ли база данных с name = settings.DATABASE_NAME, существует на самом деле или нет (для создание тестового БД)? В идеале, следует проверять только имя а не фактическое существование БД верно?

Я просмотрел исходный код django и обнаружил, что «соединение», которое используется для создания testdb, фактически создается с использованием параметров настройки DATABASE. Все это должно быть обеспокоено значениями настроек, а не их фактическим существованием. Правильно?

Answer 1

Хороший вопрос ... вы знаете, это никогда не приходило мне в голову. Короткий ответ заключается в том, что самому Django не нужно для проверки того, что DATABASE_NAME действительно существует, но ему необходимо подключиться к базе данных для создания тестовой базы данных. Большинство баз данных принимают (а некоторые требуют) DATABASE_NAME, чтобы сформулировать строку подключения; часто это происходит потому, что имя базы данных, к которой вы подключаетесь, влияет на разрешения для вашего сеанса подключения.

Поскольку тестовая база данных еще не существует, django должен сначала подключиться, используя обычные настройки.DATABASE_NAME, чтобы создать тестовую базу данных.

Итак, это работает так:

• Бегун теста Django переходит к специфичному для бэкенда обработчику базы данных
• Обработчик базы данных, специфичный для бэкэнда, имеет функцию create_test_db, которая будет использовать обычные настройки для подключения к базе данных. Он делает это с помощью простой команды cursor = self.connection.cursor(), которая, очевидно, использует обычные значения настроек, потому что это все, что она знает на данный момент.
• После подключения к базе данных специфичный для бэкенда обработчик выдаст команду CREATE DATABASE с именем новой тестовой базы данных.
• Обработчик, специфичный для бэкэнда, закрывает соединение, а затем возвращается к исполнителю теста, который меняет нормальное settings.DATABASE_NAME на имя_данных test_database_ 1020 *
• Затем тест будет выполняться в обычном режиме. Все последующие вызовы connection.cursor() будут использовать модуль обычных настроек, но теперь этот модуль имеет замененное имя базы данных
• В конце программа-исполнитель восстанавливает старое имя базы данных после вызова функции destroy_test_db специфичного для бэкенда обработчика.

Если вам интересно, соответствующий код для основной части находится в django.db.backends.creation. Посмотрите на функцию _create_test_db.

Я полагаю, что разработчики Django могли бы делать исключения на основе db-by-db, поскольку не каждая БД нуждается в текущем имени базы данных в строке соединения, но для этого потребуется небольшой рефакторинг. Прямо сейчас, функция create_test_db фактически находится в одном из базовых классов backend, и большинство реальных обработчиков бэкэнда не переопределяют ее, поэтому существует достаточное количество кода для передачи вниз и дублирования в каждом бэкэнде.