Évolution de la Base de Données

Le service Camera Manager fonctionne avec un haut niveau d'autonomie, y compris pour la gestion de son schéma de base de données. Cette page détaille le Système de Migration Déclaratif utilisé pour garantir que la structure de la base est toujours alignée avec le code.

Pourquoi des Migrations Internes ?

Dans une architecture microservices distribuée, le camera-manager peut être déployé indépendamment de l'API backend. Pour éviter de dépendre d'outils de migration externes (comme AdonisJS Ace ou Alembic) et pour assurer une auto-réparation robuste, le service inclut un moteur de migration léger intégré.

Système Déclaratif

Au lieu d'écrire des scripts de migration procéduraux ("fait ceci, puis cela"), nous définissons l'État Désiré du schéma dans src/database.py.

# database.py

SCHEMA_EVOLUTION = [
    {
        "table": "running_scripts",
        "add_columns": [
            ("status_updated_at", "TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP"),
        ],
        "drop_columns": [
            "runtime_seconds",
        ]
    }
]

Fonctionnement

Au démarrage, la fonction ensure_schema_updates() s'exécute automatiquement :

1. Inspection : Elle inspecte information_schema pour voir quelles colonnes existent actuellement pour chaque table.
2. Convergence :
   • Colonnes Manquantes : Si une colonne dans add_columns manque, elle exécute une commande ALTER TABLE ... ADD COLUMN.
   • Colonnes Obsolètes : Si une colonne dans drop_columns existe, elle exécute une commande ALTER TABLE ... DROP COLUMN.
3. Idempotence : Le système vérifie avant d'agir. Si le schéma est déjà correct, il ne fait rien. Cela rend l'exécution sûre à chaque démarrage.

Processus de Migration

1. Le Développeur ajoute une nouvelle colonne à SCHEMA_EVOLUTION.
2. Déploiement de la nouvelle image conteneur.
3. Démarrage : Le service détecte la différence de schéma et applique le correctif.
4. Prêt : Le service commence à traiter les caméras avec la structure DB correcte.