А с вашими миграциями все в порядке? / Комментарии / Хабр

Делать миграции безопасными помогает Data Vault и ему подобные - когда добавление нового поля приводит не к изменению, а к созданию новой таблицы-сателлита с теми же ключами, что у основной таблицы.

При этом меняются лишь витрины данных - добавляется join.

Ну и заполнять эту таблицу-сателлит надо отдельно.

rurikovich 17 мая в 18:39

Спасибо за полезной комментарий.
Я бы отметил что этот подход больше применим к DWH/аналитике и тд
В обычной OLTP-базе приложения он будет избыточен: больше таблиц, больше join-ов, сложнее модель и код. это мое мнение.

vlad4kr7 23 часа назад

Требование идемпотентности скрипта противоречит идеи наличия табицы истории.

Если скрипт уже выполнялся, то его не надо еще раз выполнять, все, и не будет никакой идемпотентности, если фреймворк его не вызовет вообще.

По той-же причине - такие вещи как: IF NOT EXISTS просто не рекомендуют.

ролбаки и undo миграции - серьезно?

а зачем? в проде ролбачить собрались, с дропами? а вдруг кто номер версии не ту вбил и все откатилось до 0.01, а тестировать migrate/undo каждого скрипта ?

Код можно вернуть на предыдущую версию. Базу, в которой уже удалили колонку или пересобрали таблицу, просто так назад не вернёшь.

Надо делать отдельно - миграцию базы и деплой кода. Тогда органически получается требование обратной совместимости с легким откатом аппы, плюс canary деплой, плюс Principle of Least Privilege (PoLP).

Но потом в миграциях появляется:

<validCheckSum>1:any</validCheckSum>

Если фреймворк позволяет отключать checksum, из changeset, т.е. script input, а не только и исключительно настройки запуска ci/cd, которую сделали один раз, и не трогают. ...как такое вообще можно в прод пускать?

Есть два подхода к управлению схемами:
декларативный и императивный.

декларативный - это генерить sql скрипты по коду или yaml. Зависит от кода и базы. Может налету, и применять полученный SQL к базе:
- удобно в начале разработки, особенно когда несколько чел. в одну таблицу добавляют разное.
- позволяет привязать кодовую аппы к схеме базы - требование наличия таблиц/колонок
- не рекомендуют в проде - нельзя ревью скрипта и т.к. нельзя гарантировать идемпотентность получаемого sql.
императивный - это sql скрипты руками, checksum, история выполнения.
- Полный контроль над скриптами которые идут в базу.
- flyway - например позволяет четко отслеживать и версионировать. плюс ReRunable скрипты с кодом SP/view.

есть фреймворк который может оба два, но только для постгреса.