Saviez-vous que MyClub met à jour automatiquement sa base de données lorsque le modèle évolue ?

Eh oui ! Sous le capot, notre application vérifie à chaque démarrage que la version du modèle de données correspond bien à celle utilisée dans le programme.

📘 Comment ça marche ?

Dans la table Metadata, un champ DatabaseVersion garde la trace de la version actuelle du schéma de la base.

De son côté, la classe Database de l’application mémorise dans une constante DB_VERSION le numéro attendu.

Lors de l’initialisation, la classe Database compare les deux valeurs :

• ✅ si elles correspondent, tout va bien ;
• ⚠️ si la base est plus ancienne, MyClub lance une migration automatique pour l’amener à jour ;
• 🚫 si la base est plus récente que le code, une alerte empêche le démarrage (pour éviter toute incohérence).

🔧 Les scripts de migration

Chaque évolution du modèle (ajout de table, colonne, index, etc.) doit être accompagnée d’un petit script de migration.

Ces scripts se trouvent dans app/models/database/migrators/ et portent des noms comme :

V1ToV2Migrator.php
V2ToV3Migrator.php

Chaque script implémente l’interface :

interface DatabaseMigratorInterface {
    public function upgrade(PDO $pdo, int $currentVersion): int;
}

Cette fonction applique les changements nécessaires pour passer d’une version à la suivante — par exemple ajouter une colonne, créer une table, ou mettre à jour des métadonnées.

🪄 Et le reste se fait tout seul !

Lorsqu’une nouvelle version de l’application est installée, la classe Database détecte automatiquement la différence et appelle les migrateurs successifs (V1ToV2, V2ToV3, etc.) jusqu’à atteindre la version cible.

Ainsi, les utilisateurs n’ont rien à faire : leurs données sont préservées et le schéma reste toujours compatible.

Souple, robuste et évolutif — c’est ça l’esprit MyClub ! 💪

Grâce à cette architecture, l’application peut continuer à grandir sans jamais perdre ses données.