@migration-writerLe démineur — migrations forward-only sans downtime

Le problème qu'il résout

Tu dois ajouter une colonne phone (NOT NULL UNIQUE) à la table users en prod. 5 millions de lignes. Pas de downtime acceptable. Tu écris ALTER TABLE users ADD COLUMN phone VARCHAR(20) NOT NULL UNIQUE et tu te retrouves avec une migration qui lock la table pendant 20 minutes. Catastrophe.

@migration-writer connaît les patterns pour faire ça safely en plusieurs étapes — et te donne le SQL exact pour MariaDB / Postgres / SQLite.

Comment il bosse

1. Tu lui décris le changement souhaité (ADD COLUMN, RENAME, DROP, etc.).
2. Il détecte le SGBD et la version pour adapter la syntaxe.
3. Pour chaque opération risquée, il décompose en plusieurs étapes safe.
4. Idempotent quand ça coûte rien (IF NOT EXISTS / IF EXISTS).
5. Documente la durée attendue et l'impact de lock.
6. Forward-only : pour annuler, nouvelle migration DROP/ALTER.

Exemple concret

Tu tapes

›@migration-writer ajoute colonne phone VARCHAR(20) NOT NULL UNIQUE
à users. 5M rows, MariaDB 11, prod live. Plan safe en plusieurs étapes.

Tu obtiens

## Plan en 4 migrations

### 023 — Add column (nullable, instant)
ALTER TABLE users ADD COLUMN phone VARCHAR(20) NULL;
-- Durée: instant (online sur MariaDB 10.5+)

### 024 — Backfill en chunks (script séparé)
-- scripts/backfill_phone.php loops 10000 rows/batch
-- avec SLEEP(0.1) entre batches.

### 025 — Add UNIQUE index (online)
CREATE UNIQUE INDEX uk_users_phone ON users (phone)
  ALGORITHM=INPLACE LOCK=NONE;

### 026 — Add NOT NULL constraint (après backfill 100%)
ALTER TABLE users MODIFY COLUMN phone VARCHAR(20) NOT NULL;

Pourquoi tu vas l'aimer

Quand l'utiliser

Combine avec ces agents

Questions fréquentes