Aller au contenu principal

Migrations

Statut​

Document de cadrage data — version initiale — v1.0 — relu le 2026-05-11.

Objectif​

Les migrations doivent permettre de faire évoluer la base de manière contrôlée, traçable et réversible autant que possible.

Elles sont un élément central de la gouvernance data DMV.

État actuel visible​

Le workspace contient deux familles de migrations :

  • migrations Laravel dans api/database/migrations ;
  • migrations Supabase historiques dans dmv_backoffice/supabase/migrations et dmv-public/supabase/migrations.

La source canonique exacte entre ces familles doit être clarifiée progressivement.

Migrations Laravel​

Les migrations Laravel couvrent les domaines principaux :

  • identité ;
  • territoire ;
  • acteurs ;
  • publications ;
  • communauté ;
  • monétisation ;
  • settings ;
  • PlayLoop ;
  • AssoSuite ;
  • chat ;
  • mairie ;
  • cache ;
  • jobs ;
  • tokens.

Migrations Supabase historiques​

Les migrations Supabase couvrent notamment :

  • documents et storage ;
  • tags acteurs ;
  • feature tabs ;
  • groupes ;
  • publications personnelles ;
  • modération ;
  • favoris ;
  • commune infos ;
  • stats events ;
  • astuces ;
  • RPC diverses.

Compatibilité PostgreSQL dans les migrations​

Les migrations Laravel doivent respecter les contraintes strictes de PostgreSQL :

  • UUID par défaut : ne pas utiliser ->default('') sur une colonne uuid — PostgreSQL rejette une chaîne vide comme valeur UUID invalide. Omettre le default ou utiliser ->default(DB::raw('gen_random_uuid()')).
  • Colonnes existantes : utiliser Schema::hasColumn() ou IF NOT EXISTS pour les migrations additives sur une base Supabase déjà schématisée.
  • Types stricts : PostgreSQL refuse de comparer uuid = varchar sans cast explicite — s'assurer que les clés étrangères ont le même type que la colonne référencée.

Principes de migration​

  • Une migration doit être lisible et limitée à un changement cohérent.
  • Les changements destructifs doivent être évités sans plan.
  • Les données sensibles doivent être préservées.
  • Les migrations doivent être testées avant production (base dmv_test locale).
  • Les changements de schéma doivent être alignés avec l'API.
  • Les migrations historiques ne doivent pas être modifiées sans raison forte.

Stratégie cible​

La cible est de définir :

  • source canonique des migrations ;
  • convention de nommage ;
  • processus de revue ;
  • compatibilité avec les frontends ;
  • stratégie de rollback ;
  • documentation des changements de données ;
  • synchronisation éventuelle Supabase / Laravel.

Points à clarifier​

  • Laravel devient-il la source unique des migrations ?
  • Quelles migrations Supabase restent actives ?
  • Comment migrer les RPC vers Laravel ou les conserver ?
  • Comment gérer les environnements locaux, staging et production ?
  • Comment documenter les migrations de données et pas seulement de schéma ?