Skip to main content
View as Markdown

Migrations de schéma

Sovrium fait évoluer le schéma de votre base de données automatiquement. Il compare la configuration de l'application à la base de données physique, génère le SQL approprié et l'exécute à l'intérieur d'une transaction — sans fichiers de migration écrits à la main. Le système valide les sommes de contrôle pour détecter la dérive, prend en charge le retour arrière pour récupérer après des échecs et enregistre une piste d'audit complète de chaque changement.

Il existe deux points de déclenchement : l'évolution au démarrage (la configuration a changé depuis le dernier démarrage) et la migration en direct à la publication (un brouillon publié via l'API). Les changements additifs s'appliquent en direct sans redémarrage ; les changements destructifs sont reportés à un redémarrage par sécurité.

Évolution automatique du schéma

Lorsque la configuration diffère de la base de données, Sovrium détecte le changement et applique la migration automatiquement — le tout dans une transaction afin qu'un échec partiel revienne proprement en arrière.

Changements structurels pris en charge :

# Before
tables:
  - id: 1
    name: users
    fields:
      - { id: 1, name: email, type: email }

# After — add a phone field; Sovrium generates ADD COLUMN
tables:
  - id: 1
    name: users
    fields:
      - { id: 1, name: email, type: email }
      - { id: 2, name: phone, type: single-line-text }
Classe de changement Exemples
Structurel Ajouter/supprimer/renommer des champs et des tables.
Propriété de champ Changement de type, contrainte, valeur par défaut, options, bascule requis.
Index & vue Ajouter/supprimer des index ; créer/mettre à jour des vues enregistrées.

Les ID de champ sont l'ancre de renommage — gardez l'id stable et changez le name pour renommer une colonne sans perdre de données. Voir Index & contraintes de table et Validation pour les propriétés par champ que les migrations suivent.

Validation de somme de contrôle

Sovrium calcule une empreinte du schéma pour éviter le travail de migration inutile et détecter la dérive.

  1. À la première migration, Sovrium calcule une somme de contrôle SHA-256 du schéma et la stocke.
  2. À chaque démarrage suivant, il compare la somme de contrôle du schéma actuel à celle stockée.
  3. Inchangé → le serveur démarre rapidement, sans exécuter de migration.
  4. Changé → Sovrium exécute les migrations nécessaires et enregistre la nouvelle somme de contrôle.

Cela rend les redémarrages peu coûteux lorsque rien n'a changé et garantit que la base de données correspond au schéma déclaré lorsque quelque chose a changé.

Migration en direct à la publication

Publier un brouillon via l'API d'administration en fait le schéma en direct sans redémarrage — et pour les changements additifs de structure de données, la table ou colonne physique est créée immédiatement sur le serveur en cours d'exécution.

Changement Appliqué Pourquoi
Additif (ajouter table, ajouter colonne) En direct — la table/colonne existe sur le serveur en cours d'exécution et est immédiatement interrogeable. Ajouter de la structure ne peut pas perdre de données ; sûr à appliquer sur du trafic en direct.
Destructif (supprimer/renommer colonne ou table) Reporté au redémarrage Une suppression/renommage sur un serveur en cours d'exécution avec du trafic risque une perte de données irréversible sans une action délibérée de l'opérateur.

Le pipeline de publication exécute migrer-avant-permuter : validate → vérification de concurrence optimiste → appliquer le DDL additif → insérer la ligne de version → permuter l'application en direct → réenregistrer les routes. Comme le DDL s'exécute avant la permutation des routes, les routes /api/tables/:slug/records nouvellement enregistrées ne pointent jamais vers une table qui n'existe pas encore.

Retour arrière

Lorsqu'une migration échoue, la transaction revient en arrière et le schéma est laissé dans son état cohérent précédent. Le retour arrière est actuellement disponible par programmation ; des commandes CLI de retour arrière dédiées (migrate:rollback, --to <version>, --force) sont prévues. Le registre des versions enregistre chaque version de schéma appliquée, de sorte qu'un instantané de version antérieure peut être réappliqué.

Piste d'audit

Le système de migration enregistre, pour chaque migration :

  • Horodatage de la migration
  • Numéro de version du schéma
  • Somme de contrôle du schéma (SHA-256)
  • Instantané complet du schéma
  • Opérations de retour arrière et raison

Cette piste d'audit est la source de vérité pour « quel schéma a produit cette base de données » — les auditeurs la recoupent avec le journal d'activité pour corréler les changements de données avec la version de schéma en vigueur à ce moment-là.

Gestion des erreurs

Les migrations échouent de manière bruyante et sûre. Chacun de ces scénarios interrompt avant ou pendant l'exécution et annule tout travail partiel :

Scénario Comportement
Schéma invalide Les erreurs de validation sont révélées avant le démarrage de toute migration.
Échec de migration Une erreur d'exécution SQL annule la transaction.
Erreur de connexion L'indisponibilité de la base de données interrompt l'exécution.
Violation de contrainte Un échec de clé étrangère ou de contrainte d'unicité provoque un retour arrière.

Pages connexes