Для каждого сайта нужно создавать свой settings.py?

Question

[bq911]

Для каждого сайта (django sites framework) нужно создавать свой settings.py?

Answer 1

[Владимир]

Совсем не обязательно. Зависит от ваших задач.

Например, если данные по всем сайтам у вас лежат в одной БД, то вы можете в view делать фильтрацию по домену из request:

news = News.objects.filter(site__domain=request.get_host())

А если, например, у вас на каждый сайт своя БД, то можно исходя из текущего домена указывать с какой БД работать:

db_name = get_db_name_by_host(request.get_host())
news = News.objects.using(db_name).all()

А можете использовать, что-то подобное: https://gist.github.com/gijzelaerr/7a3130c494215a0dd9b2

Comments

[bq911]

Спасибо, просто я хотел сделать чтобы в админке отображались только записи привязанные к текущему домену, поэтому добавил objects = CurrentSiteManager() в модель, и там просило SITE ID из настроек.
Теперь сделал по вашему примеру в настройках админ панели:

def get_queryset(self, request):
        qs = super().get_queryset(request)
        return qs.filter(site__domain=request.get_host())

все работает, спасибо

Только не понял в каких тогда ситуация может быть нужен SITE ID

[Владимир]

bq911, settings.SITE_ID и всё, что с этим связано — это стандартный путь достижения мультисайтовости, предлагаемый нам создателями Django. Этот путь предполагает использование для каждого сайта отдельных settings-файлов и wsgi-процессов. Этот путь отлично подходит для нескольких сайтов, но не для десятков/сотен. Поэтому я описал альтернативные варианты.

Вариант с фильтрацией очень гибкий. Вы можете использовать одну БД на все сайты. В зависимости от ситуации вы можете доставать данные для одного сайта, или нескольких, или всех сразу. Но эта свобода может легко вас запутать и вылезти боком. Например, где-то забыли применить фильтрацию — и на сайте выводятся данные, которых на нём быть не должно. С проверкой прав опять же могут быть проблемы, если вы не используете per-object проверки...

Вариант с using более жесткий и предсказуемый. Особенно, если не определять default базу данных, то без using у вас будет ошибка, что хорошо — ни один запрос в БД просто не пройдёт без вашего контроля. Плюсом бэкапы/восстановления отдельные для каждого сайта.

[bq911]

Владимир, Еще один вопрос, ответьте на коммент пожалуйста, если вы еще тут

[bq911]

Владимир, Как я писал выше, мне нужно чтобы на поддоменах в админке не отображалась лишняя инфа с других, но получается что при создании страницы у которой есть родителькая в селекте показываются все страницы (и с других поддоменов) с этим можно что то сделать?

скрин

[bq911]

Владимир, и с django_mptt_admin такая же ситуация: в таблице только нужные записи, а в иерархии все

[Владимир]

Об этом я и писал выше. С ходу не подскажу. Надо копать admin-классы, искать где формируется форма и переопределять queryset.

[bq911]

Владимир, получается что мне нужно делать разными базами, но как вы писали это подходит для нескольких сайтов, а у меня будет около 60 регионов:( что же тогда делать? Перезаписывать каждый виджет админки?)

[Владимир]

Я не очень часто использую админку Django. Предпочитаю делать свою на CBV. Делаю свой набор базовых классов, у которых при наличии у модели связи с сайтом queryset фильтруется по текущему домену. И от этих классов наследую конкретные вьюхи.

Если не хочется углубляться, тогда используйте вариант, озвученный в вашем вопросе. Делайте для каждого региона свой файл настроек. В него импортируйте общий файл настроек и определяйте базу данных для данного региона. Запускайте на каждый регион свой wsgi-процесс. Не очень экономично, зато просто )

[bq911]

Владимир, а если все же делать отдельными БД, то как задать общие модели? или общие записи в модели

[Владимир]

bq911, Django даёт такую возможность с помощью автоматического роутинга для баз данных. То есть можно указать какие модели в каких БД хранить. Но вы должны понимать, что при этом всё серьёзно усложняется. Связи ForeignKey и ManyToMany становятся невозможными между моделями в разных БД.

Поэтому, если это возможно, лучше хранить все данные по каждому сайту в разных БД.