Как настроить несколько учетных записей с отдельными базами данных для Django на одном сервере? - PullRequest
4 голосов
/ 24 ноября 2008

Какие есть варианты установки Django, чтобы у нескольких пользователей (каждый с «Учетной записью») могла быть своя собственная база данных?

Семантика довольно интуитивна. Может быть более одного пользователя для учетной записи. Учетная запись имеет уникальную базу данных (и база данных соответствует учетной записи). Картинка WordpressMU. :)

Я рассмотрел это:

  1. Внешнее решение - мультиплекс на несколько серверов / демонов

    Несколько установок Django, причем каждая установка / проект Django соответствует учетной записи, для которой устанавливается собственное DATABASE_NAME, например,

    Файловая система:

    /bob
      /settings.py (contains DATABASE_NAME="bob")
    
    /sue
      /settings.py (contains DATABASE_NAME="sue")
    

    Затем запускать экземпляр Django для каждого из bob и sue. Мне не нравится эта методология - она ​​кажется грубой и пахнет грязью. Но я уверен, что это сработает, и, исходя из предположений, это может быть самый чистый и разумный способ сделать это.

    Приложения могут храниться в другом месте; единственная вещь, которая должна быть уникальной для конфигурации django, это settings.py (и даже там, только DATABASE_NAME и т. д. должны отличаться, остальные могут быть импортированы).

    (кстати, я использую lighttpd и FastCGI.)

  2. Внутреннее решение - настройки базы данных мультиплексирования Django

    С другой стороны, я думал об одной единственной установке Django, и

    (a) Добавление префикса_ к каждой таблице базы данных, соответствующей учетной записи вошедшего в систему пользователя; или

    (b) Изменение базы данных в соответствии с учетной записью пользователя, который вошел в систему.

    Мне было бы особенно интересно посмотреть на «способ Джанго», чтобы сделать это (надеясь, что это что-то очень простое). Например, промежуточное программное обеспечение, которое принимает пользователя запроса и изменяет django.conf.SETTINGS ['DATABASE_NAME'] на базу данных для учетной записи этого пользователя.

    Это поднимает красные флаги, а именно. Это потокобезопасное? Т.е. влияет ли изменение django.conf.SETTINGS на другие процессы? Есть ли врожденная опасность при изменении django.conf.SETTINGS - будет ли уже установлено соединение с БД? Является ли перезапуск соединения с БД частью общедоступного API? - Я собираюсь взглянуть на источник Django, когда снова посмотрю на эту проблему.

    Я осознаю, что 2 (a) и (b) могут потребовать, чтобы аутентификация пользователя сохранялась и осуществлялась в другом механизме, чем ядро.

Пока что я собираюсь перейти к внешнему сопоставлению на слое веб-сервера - это самое простое и чистое на данный момент. Однако мне не нравится идея запуска демонов FastCGI для каждой учетной записи - кажется, что она тратит впустую память, особенно если будет более 2000 учетных записей. Однако я бы хотел оставить это обсуждение открытым, поскольку это интересная проблема, и решение в некоторых случаях не кажется идеальным.

Комментарии должным образом оценены. Приветствия

Ответы [ 2 ]

4 голосов
/ 24 ноября 2008

Способ Django определенно состоит в том, чтобы иметь отдельные установки с собственным именем базы данных (# 1). # 2 потребует немалых взломов с ORM, и даже тогда я не совсем уверен, что это вообще возможно.

Но учтите, вам не нужна ВЕСЬ новая установка всех моделей / видов / шаблонов сайта для каждого пользователя, просто новый файл settings.py со всеми соответствующими путями к общим исходным файлам. Кроме того, чтобы запустить все эти установки в Apache, сделайте это так, как я здесь:

<VirtualHost 1.2.3.4>
        DocumentRoot /www/site1
        ServerName site1.com
        <Location />
                SetHandler python-program
                SetEnv DJANGO_SETTINGS_MODULE site1.settings
                PythonPath "['/www'] + sys.path"
                PythonDebug On
                PythonInterpreter site1
        </Location>
</VirtualHost>

<VirtualHost 1.2.3.4>
        DocumentRoot /www/site2
        ServerName site2.com
        <Location />
                SetHandler python-program
                SetEnv DJANGO_SETTINGS_MODULE site2.settings
                PythonPath "['/www'] + sys.path"
                PythonDebug On
                PythonInterpreter site2
        </Location>
</VirtualHost>

при условии, что у вас есть /www/site1/settings.py, www / site2 / settings.py и так далее ...

Конечно, теперь вам нужно иметь основной сайт, на котором люди входят в систему, который затем перенаправляет вас на соответствующий сайт (здесь я просто обозначил его как "site1.com", "site2.com", но вы получить представление.)

1 голос
/ 24 ноября 2008

Django ORM не предоставляет несколько классов поддержки баз данных, но это определенно возможно - вам придется написать собственный менеджер и сделать несколько других настроек. У Эрика Флоренцано есть отличная статья с подробными примерами кода:

http://www.eflorenzano.com/blog/post/easy-multi-database-support-django/

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