Django игнорирует мою настройку DATABASE_ENGINE - иногда - PullRequest
0 голосов
/ 28 октября 2009

У меня есть несколько сайтов, каждый с отдельным файлом настроек - и с разными именами. Там цветочная тема для всех вариантов настроек. Мы должны держать сайты отдельно.

C:\Proj-Carnation> echo %DJANGO_SETTINGS_MODULE%
path.to.settings_carnation_win32

У нас есть много тестовых процедур, в которых не используется встроенная команда django-admin.py test, потому что это большие пакетные задания, запускаемые интерфейсом Django, и использующие Django ORM. Нам нужно использовать метод django.db.connection.creation.create_test_db() для создания новой тестовой базы данных.

Мы использовали эту тестовую процедуру довольно давно. В настоящее время он перестал работать. Мы внесли многочисленные изменения в структуру кода, обновив их до Django 1.1.1 и Python 2.6. Все возможные виновники.

Когда я запускаю Python, я вижу это.

C:\Proj-Carnation> python
Python 2.6.2 (r262:71605, Apr 14 2009, 22:40:02) [MSC v.1500 32 bit (Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> from django.conf import settings
>>> settings.DATABASE_ENGINE
INSDIE django.db.__init__, settings.DATABASE_ENGINE=''
'sqlite3'
>>> import django.db
>>> django.db.connection
<django.db.backends.dummy.base.DatabaseWrapper object at 0x00EE88B0>

Во время импорта django.db что-то настройки явно не установлены. Я добавил оператор печати (с ошибкой "INSIDE") в django.db. Настройки не установлены.

В конце концов, settings.DATABASE_ENGINE становится 'sqlite3'. Ожидается, что это «в конечном итоге» поведение: модуль settings использует технику ленивого загрузчика.

Проблема заключается в следующем: соединение, построенное из неполных настроек, является dummy базой данных базы данных. Тем не менее, окончательные настройки показывают, что двигатель будет 'sqlite3'.

В другом проекте («корневой») проблем нет. Вещи работают отлично. Настройки БД создают правильный экземпляр sqlite3.

Так что же отличается? Я в тупике. Именно параметры среды или физические деревья каталогов являются главными потенциальными проблемами.

В нерабочем C:\Proj-Carnation, PYTHONPATH равно C:\Proj-Carnation;C:\Proj-Root;C:\This;C:\That.

В рабочем корневом проекте C:\Proj-Carnation значение PYTHONPATH равно C:\Proj-Root;C:\This;C:\That.

Я ищу что-то в проекте "Гвоздика", что скрыло что-то в корневом проекте? К сожалению, у проекта Carnation есть только несколько файлов, и они находятся в пакете (local), который гарантирует, что их имена отличаются от корневого проекта.

Есть ли какая-то инициализация Django в версии 1.1.1, которая отличается? Например, есть ли в django.conf что-то не так с Python 2.6 и Django 1.1.1?

Есть ли какая-то относительная проблема импорта, которую я упустил из виду?

1 Ответ

9 голосов
/ 30 октября 2009

Нашли.

Когда ваш модуль настроек находится внутри пакета, элемент верхнего уровня __init__.py этого пакета не может импортировать любые материалы Django любого типа.

Если на верхнем уровне __init__.py, содержащем ваши настройки, есть импорт Django, этот импорт Django будет (потенциально) использовать настройки по умолчанию до создания ваших настроек.

А поскольку некоторые вещи в Django (например, соединение с базой данных) являются одиночными, то, что было создано при чтении ваших настроек, - единственное, что может когда-либо существовать.

Не кладите ничего в __init__.py в пакет, содержащий модули настроек.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...