🔐
получается что инфа о том произведена ли миграция хранится где-то в бд а не в серверном коде?
да
Size: a a a
2019 July 21
🔐
получается что инфа о том произведена ли миграция хранится где-то в бд а не в серверном коде?
в бд она нужна для синхронизации
🔐
открой табличку django_midgrations у себя в бд, там интересно покопаться в том что и как работает
y
а на сервере/локалке они чтоли рассинхронизированы?
что ты имел в виду под синхронизацией бд
y
эту таблицу получается?(django_midgrations)
🔐
что ты имел в виду под синхронизацией бд
ну, на локалке например не хватает или наоборот лишние, приводящие к конфликтам. Или наоборот в бд.
🔐
эту таблицу получается?(django_midgrations)
да посмотри ее, только не трогай)
y
да посмотри ее, только не трогай)
понял, спасибо
🔐
понял, спасибо
и синхронизируй с кодом с помощью —fake
А
ci/cd настраиваю параллельно разбираясь как должно работать(слово продакшн применил чтобы не было двусмысленности)
Лично я миграции не удаляю, а внутри докера вызваю migrate, вот и все)
🔐
Лично я миграции не удаляю, а внутри докера вызваю migrate, вот и все)
лучше сквашить перед деплоем
А
лучше сквашить перед деплоем
В смысле?
🔐
В смысле?
squashmigrations
А
Так деплой у меня заключается в сборке докер образа
А
squashmigrations
В одну соединять? Зачем?
🔐
В одну соединять? Зачем?
чтоб не валялась тонна файлов в продакшн версии
А
чтоб не валялась тонна файлов в продакшн версии
Ну не знаю, есть ли смысл или нет, все равно пока-то миграций мало) Образ получился примерно на 300 мб, меньше никак уже
🔐
и да, там все лишние тоже удаляются, в чистой миграции не нужно выполнять все действия которые ты на деве делал, типо мелких изменений в длине какого нибудь поля и тд.
🔐
В маленьких проектах мб и не критично но в больших там у тебя будут десятки если не сотни файлов миграций