Aller au contenu principal

Utiliser les migrations

Notions théoriques

Pourquoi les migrations ?

Les migrations permettent de faire évoluer le schéma de la base de données (tables, colonnes, index) de façon versionnée et reproductible, sans effacer les données existantes.

Comparaison avec Doctrine et Flyway
FrameworkOutil de migrationCommande
ASP.NET CoreEF Core Migrationsdotnet ef migrations add
SymfonyDoctrine Migrationsphp bin/console doctrine:migrations:diff
Spring BootFlyway / Liquibaseautomatique au démarrage

Le principe est identique : on décrit les changements (ajout de colonne, nouvelle table...) et un outil génère et applique les modifications SQL.

Créer une migration

Après avoir défini ou modifié une entité, on génère une migration :

# Générer le fichier de migration
dotnet ef migrations add InitialCreate

Cette commande crée un fichier dans Migrations/ du type 20241215143022_InitialCreate.cs :

// Migrations/20241215143022_InitialCreate.cs (généré automatiquement)
public partial class InitialCreate : Migration
{
// Applique la migration (CREATE TABLE, ALTER TABLE...)
protected override void Up(MigrationBuilder migrationBuilder)
{
migrationBuilder.CreateTable(
name: "articles",
columns: table => new
{
Id = table.Column<int>(nullable: false)
.Annotation("MySql:ValueGenerationStrategy",
MySqlValueGenerationStrategy.IdentityColumn),
Titre = table.Column<string>(maxLength: 200, nullable: false),
Contenu = table.Column<string>(nullable: false),
date_creation = table.Column<DateTime>(nullable: false),
EstPublie = table.Column<bool>(nullable: false),
},
constraints: table =>
{
table.PrimaryKey("PK_articles", x => x.Id);
});
}

// Annule la migration (DROP TABLE...)
protected override void Down(MigrationBuilder migrationBuilder)
{
migrationBuilder.DropTable(name: "articles");
}
}
attention

Ne modifiez jamais manuellement les fichiers de migration générés. Si vous avez fait une erreur, supprimez la migration (dotnet ef migrations remove) et recommencez.

Appliquer les migrations à la base de données

# Appliquer toutes les migrations en attente
dotnet ef database update

# Revenir à une migration spécifique (rollback)
dotnet ef database update NomDeLaMigration

Workflow typique lors d'une modification d'entité

# 1. Modifier l'entité C# (ajouter une propriété, changer un type...)
# Exemple : ajouter "public string ImageUrl { get; set; }" à Article

# 2. Générer la migration
dotnet ef migrations add AjoutImageArticle

# 3. Vérifier le fichier de migration généré (dans Migrations/)

# 4. Appliquer à la base de données
dotnet ef database update

Lister les migrations

# Voir toutes les migrations et leur état (appliquée ou non)
dotnet ef migrations list

Exemple de sortie :

20241210120000_InitialCreate (Applied)
20241215143022_AjoutImageArticle (Pending)

Supprimer la dernière migration (non encore appliquée)

dotnet ef migrations remove
attention

dotnet ef migrations remove ne fonctionne que si la migration n'a pas encore été appliquée (dotnet ef database update). Si elle est déjà appliquée, il faut d'abord faire un rollback.

Exemple pratique

Workflow complet : créer la base de données MonBlog avec la table articles.

# Étape 1 : Vérifier que les entités et le DbContext sont configurés
# (Article.cs dans Models/ et MonBlogContext.cs dans Data/)

# Étape 2 : Générer la migration initiale
dotnet ef migrations add InitialCreate

# Résultat :
# Build started...
# Build succeeded.
# Done. To undo this action, use 'ef migrations remove'

# Étape 3 : Appliquer la migration
dotnet ef database update

# Résultat :
# Build started...
# Build succeeded.
# Applying migration '20241215143022_InitialCreate'.
# Done.

Vérifier dans MySQL que la table a été créée :

-- Dans MySQL Workbench ou phpMyAdmin
SHOW TABLES;
-- Résultat : articles, __EFMigrationsHistory

DESCRIBE articles;
-- Résultat : id, Titre, Contenu, date_creation, EstPublie

La table __EFMigrationsHistory est créée automatiquement par EF Core pour suivre quelles migrations ont été appliquées.

Test de mémorisation/compréhension


Quelle commande génère un nouveau fichier de migration EF Core ?


Quelle commande applique les migrations en attente à la base de données ?


Que contient la méthode Up() dans un fichier de migration ?


Quelle table EF Core crée-t-il automatiquement pour suivre les migrations appliquées ?


Quelle commande affiche la liste des migrations et leur état (appliquée ou en attente) ?


Quel est l'équivalent EF Core de 'php bin/console doctrine:migrations:diff' de Symfony ?


TP pour réfléchir et résoudre des problèmes

Vous allez créer la base de données MonBlog via les migrations EF Core.

Étape 1 — Vérifier la configuration avant la migration

Avant de générer la première migration, vérifiez que tout est en place.


Bonne pratique - Vérifier l'environnement avant de migrer

Avant de lancer la première migration sur un projet, vérifiez : (1) que dotnet ef est installé, (2) que la chaîne de connexion dans appsettings.Development.json pointe sur la bonne base de données, (3) que MySQL est démarré. Une migration appliquée sur la mauvaise base de données peut être difficile à corriger.

Étape 2 — Créer la migration initiale


Bonne pratique - Toujours inspecter le fichier de migration généré

Avant d'appliquer une migration, ouvrez le fichier .cs généré dans Migrations/ et vérifiez que les méthodes Up() et Down() correspondent bien à vos attentes. EF Core peut parfois générer des opérations inattendues (DROP TABLE au lieu d'ALTER TABLE) qui entraîneraient une perte de données.

Étape 3 — Appliquer la migration à la base de données


Bonne pratique - Committer les migrations dans Git

Les fichiers de migration (Migrations/*.cs) doivent être committés dans Git. Ils font partie du code source et permettent à vos collègues de recréer la même base de données avec dotnet ef database update, sans avoir à partager de fichiers SQL manuellement.

📌 Une solution