Django, как получить доступ к объекту запроса в settings.py

Question

Возможно ли как-то получить доступ к объекту запроса внутри settings.py? Может быть, создав временный объект настроек, изменив его и сказав остальной «цепочке» использовать его вместо обычных settings.py?

Мне нужно, чтобы решить, какое DB-соединение использовать.

В качестве дополнительного вопроса. Если бы у меня было что-то вроде 5000 подключений к базе данных, был бы файл settings.py таким же эффективным, как и их хранение в базе данных sqlite на веб-интерфейсе? И было бы так же безболезненно обновить соединения? Или необходимо перезагрузить сервер, чтобы перехватить изменения в settings.py?

Редактировать: Чтобы прояснить, почему мне может понадобиться такое количество соединений. Я строю веб-приложение. Это SaaS, и, как и многие другие, каждая учетная запись будет иметь поддомен, на котором они могут создавать пользователей, и им не нужно будет взаимодействовать с любым другим поддоменом / учетной записью. Тогда было бы неплохо ограничить каждую учетную запись отдельной БД. Это обеспечивает дополнительную безопасность и упрощает приложение. Есть много других преимуществ, но это должно хорошо проиллюстрировать это. Вот почему я могу получить столько разных баз данных (но не столько разных физических серверов, если это будет иметь какое-либо значение).

Answer 1

Просто добавьте это для тех, кто ищет то же самое. В настоящее время это невозможно. Я создал запрос на функцию отслеживания ошибок Django (я думаю, что # 13056) и представил прототип для исправления, но я не думаю, что он будет включен в ближайшее время и, вероятно, в нем много ошибок. 1001 *

Я переместил проект во Flask, поскольку в нем есть объект g, который идеально подходит для этого.

Answer 2

Если я правильно понял, вы могли бы использовать новую систему db-маршрутизации django и выбирать базу данных «на лету» на основе экземпляра модели (например, вашего пользователя) без необходимости вызова using().

Answer 3

Я обратился к этой проблеме на сайте, которым я недавно пользовался, и решил позволить Apache / mod_wsgi сделать эту работу. Это решение добавляет немного памяти и ресурсов процессора, но для моего приложения это был лучший способ сохранить гибкость.

Apache .conf:

SetEnv DJANGO_TEMPLATE_DIR '/usr/local/www/apache22/data/django/templates/'
<VirtualHost *:80>
    ServerName encendio.whatever.com
    ServerAdmin your_admin@whatever.com
    DocumentRoot "/usr/local/www/apache22/data"
    SetEnv DJANGO_DATABASE_NAME monkeys
    SetEnv DJANGO_DATABASE_USER root
    SetEnv DJANGO_DATABASE_PASSWORD secretPass
    SetEnv DJANGO_DATABASE_PORT ''
    SetEnv DJANGO_DATABASE_HOST ''
    WSGIScriptAlias / /usr/local/www/apache22/data/django/wsgi_handler.py
</VirtualHost>

settings.py:

DATABASE_NAME =     os.environ.get('DJANGO_DATABASE_NAME', '')
DATABASE_USER =     os.environ.get('DJANGO_DATABASE_USER', '')
DATABASE_PASSWORD = os.environ.get('DJANGO_DATABASE_PASSWORD', '')
DATABASE_HOST =     os.environ.get('DJANGO_DATABASE_HOST', '')

Это позволяет вам настроить каждый сайт как VirtualHost в httpd.conf.

Answer 4

ORM Django не предназначен для переключения учетных данных базы данных в середине пути. Возможно, вы были бы счастливы с чем-то более самостоятельным, например, SQLAlchemy .