Je fais suite à l'article précédent "Symfony : effectuer une migration" où j'avais ajouté victorieusement (...) un champ à une table existante au moyen d'une migration Symfony/Doctrine.
Le cas semble plus complexe pour une modification majeure : l'ajout d'une table complète. Va t'on devoir créer de toute pièce un fichier de migration en décrivant TOUS les champs de ladite table, ce qui sera laborieux si les champs sont nombreux ? Non ! Il suffit d'une ligne de commande. !!
Le point de départ est le même que pour l'article précédent :
- version de Symfony : 1.3/1.4
- le fichier /config/doctrine/schema.yml existe et est juste (= il a servi à construire la DB)
- les Classes (models, filters, forms) sont à jour
- on a construit la DataBase et les Classes avec la commande php symfony doctrine:build --all, avec des fixtures. Mais c'était le départ : maintenant LA DB EST PLEINE ET LES DONNÉES NE DOIVENT PAS ÊTRE EFFACÉES !! Pas question donc de refaire cette commande pour eraser toute la DB !!- on veut tester notre projet en LOCAL puis appliquer les modifications en distant.
Pour les changement sur notre serveur LOCAL, on procède par étapes successives :
1. Déterminer l'état de départ
php symfony doctrine:generate-migrations-diff
-> Cette commande compare les Classes(models, filters, forms) et le schema.yml.
Dans notre cas, on obtient :
Could not generate migration classes from difference
Ce qui est normal, puisque tout est conforme (c'est notre point de départ) ...
Ceci permet néanmoins de créer dans la DB la table migration_version qui va enregistrer les versions de la DB (version 2, 3, etc ...). On sait à quelle version se trouve notre DB.
php symfony doctrine:migrate
-> cette commande note la version actuelle de la DB en interrogeant cette table migration_version. On obtient sans surprise :
>> doctrine Already at migration version 0
2. Modifier le schema.yml
On modifie notre /config/doctrine/schema.yml. On crée une nouvelle table.
ex :
MadatabaseMatable:
actAs:
Timestampable: ~
I18n:
fields: [intitule]
columns:
id: { type:integer(8), primary:true, autoincrement:true }
intitule: { type:string(50), notnull:true }
attachment: { type:string(255), notnull:false }
3. Comparer le nouveau schema avec les anciennes Classes
On utilise notre commande de comparaison (qui va cette fois trouver une différence entre le schema.yml et les Classes(models, filters, forms) :
On utilise notre commande de comparaison (qui va cette fois trouver une différence entre le schema.yml et les Classes(models, filters, forms) :
php symfony doctrine:generate-migrations-diff
-> Symfony/Doctrine génère alors un fichier de migration (ici deux car il y a le fichier i18n) dans /lib/migration/doctrine.
Ex :
4. Mettre à jour les Classes et la DB
php symfony doctrine:build --all-classes --and-migrate
-> cette commande va créer les nouvelles Classes(models, filters, forms) et créer dans la DB les deux tables. Le reste de la DB (données et structure) reste inchangé.
Ex :
1301053712_version1.php
1301053713_version2.php
4. Mettre à jour les Classes et la DB
php symfony doctrine:build --all-classes --and-migrate
-> cette commande va créer les nouvelles Classes(models, filters, forms) et créer dans la DB les deux tables. Le reste de la DB (données et structure) reste inchangé.
+++++
Pour mettre à jour notre serveur DISTANT :
- étape 1
- transfert du schema.yml
- php symfony doctrine:generate-migrations-diff (ou transfert des migrations déjà réalisées. Attention : le dossier /lib/migration/doctrine doit appartenir au user du ftp. Faire donc un chown -R MonLoginFtp.psaserv migration/ pour ce faire)
- php symfony doctrine:build --all-classes --and-migrate
Pour réaliser cette migration, j'ai eu besoin des posts suivants :
0 commentaires:
Enregistrer un commentaire