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.

L'évolution du schéma s'exécute au démarrage : lorsque la configuration sur le disque diffère de la base de données, Sovrium génère et applique le SQL nécessaire dans une transaction, puis enregistre la nouvelle version du schéma. La configuration est uniquement du code : vous faites donc évoluer le schéma en éditant votre app.ts / app.yaml puis en redémarrant (ou en redéployant). Il n'existe aucune API d'édition de schéma à l'exécution, et sovrium reload rafraîchit l'identité de configuration d'un serveur en cours sans appliquer de changement de schéma — un changement de schéma prend effet au prochain démarrage.

É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 }

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é.

Appliquer un changement de schéma

Pour changer votre schéma, éditez le fichier de configuration puis redémarrez le serveur (ou redéployez). Au démarrage suivant, Sovrium compare la nouvelle configuration à la base de données et applique la migration dans une transaction avant que l'application ne commence à servir du trafic : une table ou colonne nouvellement déclarée existe donc au moment où ses routes /api/tables/:slug/records sont enregistrées — les routes ne pointent jamais vers une table qui n'existe pas encore. Si la migration échoue, la transaction revient en arrière et le serveur refuse de démarrer sur un schéma incohérent, plutôt que de servir une base de données à moitié migrée.

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. L'historique de migration 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 :

Pages connexes

• Infrastructure de base de données — les moteurs SQLite/PostgreSQL que les migrations ciblent.
• Index & contraintes de table — les définitions d'index et de contraintes que les migrations appliquent.
• Validation — les règles au niveau du champ et de la table suivies au fil de l'évolution.
• Surveillance de l'activité — le flux d'audit corrélé aux versions de schéma.
• Tableau de bord d'administration — config/version rapporte le runtime et le build actifs.