Mise à jour du schéma de la doctrine ou migrations de la doctrine
Quels sont les avantages pratiques de Doctrine Migrations par rapport à l'exécution d'une mise à jour de schéma?
Sécurité?
La commande orm:schema-tool:update (doctrine:schema:update dans Symfony) vous avertit
Cette opération ne doit pas être exécutée dans un environnement de production.
mais pourquoi est-ce? Bien sûr, il peut supprimer des données, mais une migration aussi.
La flexibilité?
Je pensais pouvoir personnaliser mes migrations pour ajouter des éléments tels que les valeurs par défaut des colonnes, mais cela ne fonctionne souvent pas, car Doctrine remarquera la différence entre le schéma et le code du prochain diff et écrasera vos modifications.
Lorsque vous utilisez le schema-tool, aucun historique de la modification de la base de données n'est conservé, ce qui constitue un inconvénient majeur dans un environnement de production/de transfert.
Supposons que vous ayez une structure de base de données compliquée dans un projet réel. Et dans le prochain changeset vous devez modifier la base de données d’une manière ou d’une autre. Par exemple, les téléphones de contact de vos utilisateurs doivent être stockés dans un format différent, pas une VARCHAR, mais trois colonnes SMALLINT pour le code de pays, l'indicatif régional et le numéro de téléphone.
Eh bien, ce n'est pas si difficile de trouver une requête qui va chercher les données actuelles, les séparer en trois valeurs et les réinsérer. C'est à ce moment que les migrations entrent en jeu: vous pouvez créer vos nouveaux champs, puis effectuer les transformations et enfin supprimer le champ qui contenait les données auparavant.
Et encore plus! Vous pouvez même décrire le processus en arrière (la migration down), lorsque vous devez annuler les modifications introduites dans votre migration. Supposons que quelqu'un, quelque part, s'appuie fortement sur le format du champ VARCHAR et que, maintenant que vous avez modifié la structure, son code ne fonctionne pas comme prévu. Donc, vous exécutez migration:down, et tout est annulé. Dans ce cas spécifique, il vous suffirait de récupérer l'ancienne colonne VARCHAR et de concaténer les valeurs, puis de supprimer les champs.
L'outil de migration de Doctrine fait la plupart du travail à votre place. Lorsque vous différez votre schéma, il génère toutes les up et down nécessaires. Il vous suffit donc de gérer les données susceptibles d'être endommagées lors de l'application de la migration.
En outre, les migrations permettent aux autres développeurs de votre équipe de savoir quand il est temps de mettre à jour leurs schémas. Avec seulement le schema-tool, vos coéquipiers devraient exécuter doctrine:schema:update chaque fois qu’ils tirent, car ils ne sauraient pas si le schéma a vraiment changé.
Lorsque vous utilisez des migrations, vous voyez toujours qu'il y a des mises à jour dans le dossier des migrations, ce qui signifie que vous devez mettre à jour votre schéma.
Je pense que vous avez vraiment cloué sur la sécurité. Avec Migrations, vous pouvez revenir à un autre état de la table (comme vous pouvez le faire avec le contrôle de version Git). Avec la commande schema update, vous ne pouvez mettre à jour que les tables. Aucun journal n'est conservé pour permettre le retour en cas d'échec avec des données déjà enregistrées dans ces tables. Je ne sais pas exactement, mais une migration n'enregistre-t-elle pas également les données de la table correspondante mise à jour? Ce serait essentiel à mon avis, sinon il n'y a pas de grande raison de les utiliser.
Donc, oui, je pense personnellement que la principale raison d'utiliser les migrations dans un environnement de production est la sécurité et peut-être un peu de flexibilité. La sécurité serait le gagnant ici, je pense :)
J'espère que cela t'aides.
edit: Voici une autre réponse avec des références aux documents Symfony: Est-il prudent d'utiliser les migrations de doctrine2 dans un environnement de production avec symfony2 et php
Vous ne pouvez pas non plus effectuer de mises à jour volumineuses avec une migration de doctrine simple. J'aime essayer de mettre à jour l'index sur la base de données de 30 millions d'utilisateurs. Comme il faudra beaucoup de temps pendant que votre application ne sera pas accessible.