Migrations PostgreSQL

Migrations de l’application#

packages/database applique les migrations sous verrou avec checksums. Le démarrage vérifie les namespaces core, content, editor, theme_updates, maintenance, services, extensions, navigation, seo, integrations, languages et retention. Une divergence de checksum doit être diagnostiquée, jamais masquée. Une installation neuve vérifie PostgreSQL 16 ou supérieur et un rôle limité avant de migrer ; une base étrangère est refusée.

pnpm cms migrate:status
pnpm cms migrate

Ajoutez une migration au module concerné ; ne réécrivez pas une version déjà appliquée. Les migrations du core historique sont dans packages/core/src/schema.ts, celles des nouveaux domaines dans leurs modules dédiés.

Migrations d’une extension#

migrations: [{
  version: 1,
  name: "create_example_records",
  up: "CREATE TABLE example_records (id uuid PRIMARY KEY, label text NOT NULL)",
}]

Chaque plugin possède son namespace, ses versions, checksums et verrou. L’activation applique ses migrations dans la transaction. Une mise à jour applique les nouvelles migrations d’un module inactif tout en le laissant inactif. Préfixez les tables pour éviter les collisions entre auteurs.

Schémas de contenus et compatibilité#

L’éditeur de types utilisateur vérifie puis applique une transformation versionnée des contenus existants. Les renommages, valeurs par défaut et abandons explicites sont distincts des migrations SQL du plugin. Les snapshots historiques ne sont pas convertis automatiquement.

1. Décrivez la transformation et les versions encore compatibles.
2. Vérifiez sauvegarde et restauration sur une cible isolée.
3. Testez une base déjà remplie avec données invalides et modifications concurrentes.
4. Contrôlez la migration en staging avant la production.

Retour arrière#