Это началось как комментарий, но я подумал, что постараюсь не создавать последовательный комментарий.
Причина, по которой это работает в режиме разработки, заключается в том, что сервер dev автоматически перезагружает любые файлы (например, urls.py), которыеменять.Этого не происходит (и вы не хотите, чтобы это произошло) на рабочем сервере.У меня никогда не было необходимости делать это самому, поэтому я внимательно изучаю код и документы, чтобы увидеть, где могут быть зацепки.
Что ж, потратив на это около 45 минут, мой ответ кажется ... Вы не можете сделать это, по крайней мере, нелегко.Обратите внимание, что все номера строк ниже взяты из Django 1.3.1.
Django инициализирует ваши URL-адреса из модуля, указанного в вашем файле настроек, как ROOT_URLCONF
, обычно urls
.Эта инициализация несколько дорогая, и Django старается изо всех сил кэшировать все, что может.
В BaseHandler.get_response()
(django/core/handles/base.py
строка 83) urlresolvers.set_urlconf()
вызывается с использованием модулей urls, названных в settings.ROOT_URLCONF
.По сути, это глобальные, зашитые знания о том, где находится конфигурация URL.Из-за кэширования он инициализирует ваши URL только один раз на поток .Это означает, что каждый поток на веб-сервере, который обрабатывает ваши запросы Django, должен быть предупрежден о необходимости сбрасывать и инициализировать его URL-адреса каждый раз, когда происходит изменение базы данных, и это само по себе усложняется.
Anальтернативным методом будет либо создание супер-шаблона , который вызывает представление, которое, в свою очередь, выполняет вызов БД.Другой подход состоит в том, чтобы обработать это в классе middleware , где вы проверяете на ошибку 404, проверяете, является ли шаблон одной из ваших категорий, а затем проверяете там БД.Я делал это в прошлом, и это не так плохо, как кажется.Посмотрите на код django/contrib/flatpages
для простой реализации этого подхода.