Собственная миграция нужна, когда изменения схемы недостаточно. Например, вы добавили heading и хотите заполнить его из прежнего title. Admingen создаёт SQL-файл с очередным номером в общей последовательности system/generated/custom; запросы внутри пишете вы.
Создать и зарегистрировать файл
admingen-cli migration create --project ./docs-demo --name backfill_article_heading
Тот же вызов с общим параметром пути:
admingen-cli --path ./docs-demo migration create --name backfill_article_heading
| Флаг | Значение |
|---|---|
--project PATH |
Корень generated-проекта; при отсутствии используется --path. |
--name NAME |
Имя из строчных букв, цифр и подчёркиваний. |
Результат содержит номер и путь вида backend/migrations/custom/NNNNNN_custom_backfill_article_heading.sql. Файл сразу регистрируется в backend/migrations/manifest.json; отдельные accept/register не нужны.
Команда не подключается к БД и не исполняет SQL. Из корня созданного приложения можно использовать короткую форму:
make migration-new NAME=backfill_article_heading
Написать SQL и применить миграцию
- Откройте созданный файл и инструкцию
backend/migrations/custom/README.md. - Напишите SQL для реальной схемы. В примере нужно заполнить heading из title до удаления title.
- Сохраните SQL и migration manifest в системе контроля версий.
- Из каталога приложения примените миграции:
cd docs-demo
make migrate
Следующая генерация учтёт занятый номер. После применения не меняйте SQL и не перенумеровывайте файл. Для исправления создайте следующую миграцию. Ранее зарегистрированные custom-файлы сохраняют свои пути.
Проверка ограничений БД
make constraints-list, make constraint-validate NAME=... и make constraints-validate относятся к созданному приложению. Они показывают и проверяют ограничения, но не исправляют нарушающие их данные.
Значение migrate --check и --verify и порядок диагностики описаны в миграциях и ограничениях. Другие операции обслуживания — в командах приложения.