Initialisation de la crate `migration` (une seule fois)

runique makemigrations écrit des fichiers .rs dans migration/src/, mais ne crée ni le Cargo.toml ni le binaire CLI qui les compile — migration/ doit déjà exister comme crate Rust compilable avant la première génération.

sea-orm-cli migrate init --migration-dir migration/src

Deux ajustements manuels dans migration/Cargo.toml après l'init :

Activer au moins un runtime + un driver DB dans les features de sea-orm-migration — la liste générée par migrate init est vide (seulement des commentaires en exemple).
Ajouter runique en dépendance : les migrations générées référencent runique::prelude::migrations_table pour les tables eihwaz_* (cf. plus bas).

[dependencies]
tokio = { version = "1", features = ["macros", "rt", "rt-multi-thread"] }
runique = { version = "3.0.0", features = ["sqlite"] }

[dependencies.sea-orm-migration]
version = "2.0.0"
features = ["runtime-tokio-rustls", "sqlx-sqlite"]

Adapter sqlite/sqlx-sqlite à votre moteur cible (postgres/sqlx-postgres, mysql/sqlx-mysql) — cf. Base de données.

runique makemigrations écrase ensuite migration/src/lib.rs et supprime le fichier de migration placeholder que sea-orm-cli migrate init a créés — rien d'autre à faire de ce côté.

Workflow en deux étapes

1. Générer les fichiers de migration

runique makemigrations lit vos entités déclarées dans src/entities et génère les fichiers de migration correspondants :

runique makemigrations --entities src/entities --migrations migration/src

Ce que makemigrations fait en une seule commande :

Passe	Source	Résultat
1 — Tables app	Blocs `model!{}` dans `src/entities`	`CREATE TABLE` / `ALTER TABLE`
2 — Extensions framework	Blocs `extend!{}` dans `src/entities`	`ALTER TABLE ADD/DROP COLUMN`
3 — Tables du framework	Automatique	Migrations `eihwaz_*` placées en tête de `lib.rs`

2. Appliquer les migrations

sea-orm-cli migrate up --migration-dir migration/src

Changements destructifs — `--force`

Avant d'écrire quoi que ce soit, makemigrations détecte les changements destructifs et refuse de générer la migration, sauf si vous passez --force :

DROP COLUMN (perte de données)
changement de type d'une colonne
passage nullable → not null (nécessite une valeur par défaut ou un backfill)
réduction de longueur d'une colonne (max_length plus petit) : des valeurs plus longues seraient tronquées ou refusées
suppression d'une clé étrangère (risque d'enregistrements orphelins)
ajout d'une FK ON DELETE CASCADE sur des données existantes (suppressions en cascade possibles)

runique makemigrations --force

Le contrôle couvre aussi bien les tables d'application (model!{}) que les extensions de tables framework (extend!{}).

Génération atomique

La génération est tout ou rien. Les changements des modèles et des blocs extend!{} sont d'abord planifiés en mémoire, validés (contrôle destructif ci-dessus), puis écrits en un seul lot. En cas d'erreur d'écriture, tous les fichiers générés sont annulés et les snapshots ainsi que lib.rs sont restaurés dans leur état initial.

Clés étrangères et moteur cible

Les fichiers générés sont communs à tous les moteurs : ce qui ne concerne qu'un moteur est choisi à l'exécution, dans le fichier.

Les FK sont déclarées dans le CREATE TABLE, sur tous les moteurs ; les tables référencées sont créées avant celles qui les référencent.
Cycle (deux nouvelles tables qui se référencent l'une l'autre) : sous SQLite, qui ne vérifie une FK qu'à l'écriture des lignes, la clé reste dans le CREATE TABLE ; sous PostgreSQL / MySQL / MariaDB, la clé qui ferme le cycle est ajoutée par un ALTER TABLE une fois la table visée créée. Le choix se fait à l'exécution : le même fichier marche sur tous les moteurs.
Chaque colonne de belongs_to reçoit un index idx_<table>_<colonne>.

De même, les enums deviennent un CREATE TYPE … AS ENUM sous PostgreSQL uniquement (un VARCHAR ailleurs) : changer de moteur ne demande pas de régénérer les migrations.

Tables framework — fournies automatiquement

Runique injecte automatiquement quatre migrations dans votre lib.rs sans que vous ayez à les définir :

Migration	Crée	Ordre
`EihwazUsersMigration`	`eihwaz_users` (id, username, email, password, is_active, is_staff, is_superuser, created_at, updated_at)	1er
`EihwazSessionsMigration`	`eihwaz_sessions` (persistance des sessions authentifiées)	2e
`AdminTableMigration`	`eihwaz_groupes`, `eihwaz_groupes_droits`, `eihwaz_users_groupes`, `eihwaz_history`	3e
`EihwazResetTokensMigration`	`eihwaz_reset_tokens` (tokens de réinitialisation de mot de passe, hashés)	4e

Vous n'avez pas besoin de déclarer eihwaz_users dans vos entités.

Étendre une table framework — `extend!{}`

Pour ajouter des colonnes à une table framework, utilisez extend!{} dans un fichier d'entité :

use runique::prelude::*;

extend! {
    table: "eihwaz_users",
    fields: {
        avatar: image [upload_to: "avatars/"],
        bio: textarea,
        website: url [required],
    }
}

makemigrations détecte ces blocs et génère les ALTER TABLE ADD COLUMN correspondants. Le snapshot d'extension est stocké dans migration/src/snapshots/runique/eihwaz_users.rs.

Tables extensibles :

eihwaz_users · eihwaz_groupes · eihwaz_sessions
eihwaz_users_groupes · eihwaz_groupes_droits

Étendre une table inconnue déclenche une erreur à la compilation.

Autres commandes de migration

sea-orm-cli migrate down --migration-dir migration/src   # Annuler la dernière migration
sea-orm-cli migrate status --migration-dir migration/src # Voir l'état des migrations

runique makemigrations est le seul outil à utiliser pour générer les fichiers de migration. Ne pas utiliser sea-orm-cli migrate generate : Runique maintient ses propres snapshots et ordre chronologique.

Migrations (SeaORM)