Миграции

Каталог миграций: apps/core-api/prisma/migrations. Провайдер БД зафиксирован в migration_lock.toml — PostgreSQL.

Миграции применяются штатными командами Prisma через Nx-таргеты сервиса core-api (см. apps/core-api/project.json):

nx run core-api:prisma:migrate:dev → npx prisma migrate dev (разработка, генерирует и применяет миграции);
nx run core-api:prisma:db:push → npx prisma db push (stage/production, синхронизация схемы без файлов миграций);
nx run core-api:prisma:schema:generate → npx prisma generate (перегенерация клиента).

Хронология миграций

Дата / имя миграции	Что делает
20260830000000_baseline	Создаёт схему целиком: 61 таблица, 42 enum-типа, все внешние ключи и индексы. Плюс три инварианта уровня БД в raw SQL: `settlements_amounts_sum_to_hold`, `queue_items_open_dedup`, `users_on_roles_single_platform_role`.

История начинается заново с этой миграции. Прежние 14 папок (20251025115636_init … 20260321000000_add_admin_service) удалены, а не дополнены новой миграцией поверх них.

Почему история схлопнута

Решение №31 журнала архитектурной сессии (2026-08-21, шаг 8): чистый baseline вместо expand/backfill-цикла. Обоснование зафиксировано там же (session-decisions-log.md, step-8-migration.md):

боевых данных на момент решения нет — всё, что лежит в базах окружений, тестовое;
целевая схема расходится с прежней настолько (31 новая модель, переработанный Project, политика Restrict на всей сделочной цепочке), что пошаговая миграция была бы длиннее и рискованнее, чем пересоздание;
цепочка из 14 миграций описывала эволюцию, которой в целевой модели уже не существует, и накатывалась дольше, чем один CREATE-скрипт.

Практическое следствие: окружения пересоздаются, а не мигрируют. Существующая база приводится к новой схеме через prisma migrate reset (dev) либо пересозданием базы и накатом baseline’а (stage/production), после чего запускаются сиды — без них не будет даже строк roles (см. seeds).

Инварианты внутри baseline’а

Хвост migration.sql — не сгенерированный Prisma DDL, а три правила, которые Prisma Schema Language выразить не умеет (CHECK-констрейнты и частичные уникальные индексы). Каждое снабжено в файле комментарием с обоснованием и ссылкой на источник решения. Что именно они запрещают — в разделе «Инварианты на уровне БД» database-schema.md.

Индекс users_on_roles_single_platform_role содержит в предикате литеральные uuid трёх платформенных ролей. Эти же значения лежат в roles.constants.ts и в сиде ролей. Изменение id роли — это миграция с пересозданием индекса, а не правка константы.

Следующие миграции

Baseline применён на dev и stage, поэтому там правится не он, а новая миграция поверх. Прод получает baseline целиком в единице G2, в окне обслуживания: до этого момента история миграций на боевой базе — прежняя:

изменить apps/core-api/prisma/schema.prisma;
nx run core-api:prisma:migrate:dev — Prisma сгенерирует папку с новым DDL;
если изменение вводит инвариант, который PSL не выражает, дописать raw SQL в ту же миграцию и закрыть его интеграционным тестом в apps/core-api-e2e/src/schema/;
обновить database-schema.md и добавить строку в хронологию выше.