MS
утренний вброс: как относитесь к схлопыванию миграций?
Size: a a a
2017 April 12
MS
Даже гемчик есть удобный для этого https://github.com/jalkoby/squasher
AS
О круто, а мы их удаляли когда за 200 перевалило, и собирали одну миграцию на текущую схему, главное было таблицу с записями о миграций на проде обновить)
MS
Ну по сути почти то же и происходит
AS
Вообще наверное кучу миграций можно к тех долгу относить, что б время от времени подчищать) У нас скорость сборки проекта на CI существенно уменьшилось после того как миграции сбросили.
RS
не внедрял, пока не было необходимо
DM
В рельсах же была какая-то команда для этого
DM
Или я с джангой путаю
DM
Вспомнил, в рельсах же есть schema.rb, если база поднимается с нуля и не гоняются все миграции
AS
Так там же понт что миграция новая может быть корявая, и step-by-step схема не соберется в итоге. По этому нужно через все миграции проходить.
AS
ну в джанге по крайней мере это было бы не надежно
DM
Так там же понт что миграция новая может быть корявая, и step-by-step схема не соберется в итоге. По этому нужно через все миграции проходить.
Можно откатиться к предыдущей миграции и сделать схему для неё
DM
Могу ошибаться, два года не работал с рельсами
AS
Можно откатиться к предыдущей миграции и сделать схему для неё
Да можно и так, мы делали репетицию поставки, то есть как собирается проект так и деплоится. А разница в прогоне миграций эт не очень гуд)
DM
Да можно и так, мы делали репетицию поставки, то есть как собирается проект так и деплоится. А разница в прогоне миграций эт не очень гуд)
Сиайку же можно научить
AS
Ну да, я к тому что на CI миграции надо прогонять как на продакшене
DM
Ну а как же ещё?)
AS
А если собирать схему основываясь на модели, и откатывать на предыдущую миграцию (тут надо учесть количество новых миграций в билде, 1, 3, или 10)
AS
по этому костыльно чет звучит по мне)