Grande nouvelle : la taverne ouvre son site pour de vrai. Il tournera sur un serveur, avec une base de données qui garde les réservations, les avis et les comptes des employés.
Jusqu'ici, chaque exercice préparait la base avec doctrine:schema:update --force : Doctrine comparait les entités à la base et modifiait les tables sur-le-champ. Pratique dans l'aperçu, dont la base repart de zéro à chaque chargement. Dangereux en production : aucune trace de ce qui a changé, aucun retour possible, et une colonne renommée peut disparaître avec ses données.
En production, on écrit chaque changement de schéma dans une migration : un fichier PHP versionné avec le code, relu, joué une fois sur chaque serveur.
Votre mission
L'aperçu est cassé : cette fois, plus rien ne crée les tables. Dans la console :
- générez la première migration :
doctrine:migrations:diff; - relisez le fichier qui s'ouvre dans l'éditeur, et décrivez-le dans
getDescription(); - jouez-la :
doctrine:migrations:migrate; - rechargez la carte :
app:charger-carte, puis l'aperçu.
Ce que contient une migration
up(): ce qu'il faut exécuter pour avancer (créer les tables) ;down(): ce qu'il faut exécuter pour revenir en arrière (les supprimer) ;- un nom daté (
Versionsuivi de la date et de l'heure) : les migrations se jouent dans l'ordre.
Doctrine retient les migrations déjà jouées dans la table doctrine_migration_versions : relancer migrate ne rejoue rien.
Le bon réflexe
Le fichier généré dit lui-même « please modify it to your needs ». Doctrine devine, il ne sait pas : une migration se relit toujours avant d'être jouée. Vous verrez très vite pourquoi.