PrompTom
Все скилы

Миграция без потери данных

db-migrationPROбаза данныхмиграции

Меняет схему так, чтобы старый и новый код пережили её оба — и откат тоже.

Что делает

  • Срабатывает на «добавь колонку», «переименуй поле», «поменяй тип», «нужна миграция».
  • Исходит из того, что старый и новый код какое-то время работают одновременно, а при откате — долго. Отсюда всё остальное.
  • Переименование разбивает на четыре выката: добавить, писать в обе, перенести, переключить чтение, потом удалить. Переименование одним шагом ломает все запущенные копии старого кода разом.
  • Удаление ставит отдельным выкатом позже кода, который перестал этим пользоваться. Иначе откат оставляет код, ждущий несуществующую колонку.
  • Спрашивает число строк до, а не после: перенос на десять тысяч — это команда, на десять миллионов — пакетная работа, иначе блокировка кладёт сайт.
  • Требует написать и прочитать обратную миграцию, а если данные не вернуть — сказать об этом прямо в файле, чтобы человек в три часа ночи знал заранее.
  • Проверяет на копии боевых данных: пустая база доказывает только то, что синтаксис разобрался.

Зачем он нужен

Миграции ломаются не на синтаксисе, а на том, что кто-то забыл про пять минут, когда работают обе версии кода. Дубликаты, мешающие уникальному индексу, пустые значения в колонке, которая становится обязательной, блокировка на большой таблице — всё это видно только на настоящих данных и только если задать вопрос заранее.

Куда положить

  1. 1Создайте в проекте папку .claude/skills/db-migration
  2. 2Положите в неё файл SKILL.md с текстом ниже
  3. 3Всё. Claude Code подключит скил сам, когда задача подойдёт под описание

Чтобы скил работал во всех проектах, а не в одном, положите его в ~/.claude/skills вместо папки проекта.

Файл SKILL.md

# Changing a schema while the app is running

The old code and the new code overlap in production for at least a few
minutes, and on a rollback for much longer. Every migration must leave
both able to run.

That single constraint decides almost everything below.

## The safe shapes

**Adding a column:** nullable, or with a default. A `NOT NULL` column
with no default fails the moment old code inserts a row.

**Renaming:** never in one step. Add the new column, write to both,
backfill, switch reads, stop writing the old one, drop it later. Four
deploys, not one. A rename in a single migration breaks every running
instance of the old code at once.

**Changing a type:** the same shape as a rename. Widening (int to
bigint, varchar to text) is usually safe in place; narrowing never is.

**Dropping anything:** in a separate, later deploy from the code that

Файл скила входит в PRO-подборку

Открыть доступ
Миграция без потери данных — PrompTom