Size: a a a

Django [ru] #STAY HOME

2019 November 07

A

Andrey in Django [ru] #STAY HOME
Sergey Matveyev
Всем привет, помогите разобраться пожалуйста.
В проекте три БД - собственная (постгре), и две от сторонних сервисов, одна MSSQL, другая MySQL.
Постоянный трабл в том, что вторая база на mssql доступна только через VPN, который в свою очередь доступен только на рабочем сервере, не на тестовом. Проблемой это становится например при запуске manage.py makemigrations app_name - джанга проверяет изменения в этих двух базах и говорит что база mssql не доступна. Подскажите, можно как-то запускать makemigrations таким образом, чтобы проверялась только конкретная бд?
--database=any_bd
источник

SM

Sergey Matveyev in Django [ru] #STAY HOME
Andrey
--database=any_bd
Хм, а вы с inspectdb не путаете?
При makemigrations говорит "unrecognized arguments"
источник

DT

Dan Tyan in Django [ru] #STAY HOME
ну да походу makemigrations нет аргумента —database
источник

SM

Sergey Matveyev in Django [ru] #STAY HOME
Странно, но в списке вообще ничего про уровень БД
источник

DT

Dan Tyan in Django [ru] #STAY HOME
с другой стороны миграции делаются на дев сервере
источник

A

Andrey in Django [ru] #STAY HOME
путаю, виноват
источник

SM

Sergey Matveyev in Django [ru] #STAY HOME
Dan Tyan
с другой стороны миграции делаются на дев сервере
Не, я отказался от этой практики.
источник

SM

Sergey Matveyev in Django [ru] #STAY HOME
Потому что либо нужно склеивать их
источник

SM

Sergey Matveyev in Django [ru] #STAY HOME
Либо готовить специальные миграции
источник

SM

Sergey Matveyev in Django [ru] #STAY HOME
Ну после внесения всех изменений.
источник

SM

Sergey Matveyev in Django [ru] #STAY HOME
На проде сразу делаю.
источник

SM

Sergey Matveyev in Django [ru] #STAY HOME
**В смысле что я в репу миграции не выкладываю, я к этому. Извиняюсь, коряво описал
источник

A

Andrey in Django [ru] #STAY HOME
Sergey Matveyev
**В смысле что я в репу миграции не выкладываю, я к этому. Извиняюсь, коряво описал
а вот так делать явно не надо
источник

A

Andrey in Django [ru] #STAY HOME
миграции - часть кода
Они однозначно должны быть в репозитории и под гитом
источник

SM

Sergey Matveyev in Django [ru] #STAY HOME
А зачем?
источник

SM

Sergey Matveyev in Django [ru] #STAY HOME
Я эту идею здесь кстати пару месяцев назад обсуждал
источник

SM

Sergey Matveyev in Django [ru] #STAY HOME
Выяснилось что так достаточно многие делают.
источник

AH

Anthony Hopkins in Django [ru] #STAY HOME
Товарищи знатоки, надо сделать модель страницы для того чтобы ПМ\сеошник мог с админки управлять контентом на сайтах. Но контент это не какой-то обычный текст из бложика или описание на карточке товара. Контент это всякие мелочные надписи и картиночки разбросанные в разных местах по всему шаблону, всякие штуки типа слайдеров с картинками, заголовками и  описаниями на них. На каждой странице контент разный.

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

Дефолтные джанговские инлайны какие то неудобные и не позволяют выбрать тип поля(charfield, textfield, imagefield). django-eav нравится тем, что можно будет обращаться к созданному атрибуту через точку(.eav.attr), но в админке он выводит поля сразу для всех существующих атрибутов, а не только для тех которые указаны у данной страницы, и не позволяет из админки создать новый атрибут.

Какие советы можете мне дать? Стоит ли смотреть в сторону jsonfield? Или надо вдоль и поперек пролазить в коде django-eav2? Придется ли в любом из выбраных вариантов сильно кастомизировать админку? Может у кого есть реализованый вариант с eav, но попроще чем тот который есть в django-eav2?
источник

D

Denis in Django [ru] #STAY HOME
хелп
источник

D

Denis in Django [ru] #STAY HOME
в форме токен передаю, но в верстку не вставляется (в браузере не отображается в верстке)
источник