Mise à jour du schéma de la Doctrine ou migration de la Doctrine
Quels sont les avantages pratiques des Migrations doctrinales par rapport à une simple mise à jour de schéma?
sécurité?
la commande orm:schema-tool:update ( doctrine:schema:update in Symfony) avertit
cette opération ne doit pas être exécutée dans un environnement de production.
mais pourquoi cela? Bien sûr, il peut supprimer des données, mais une migration aussi.
flexibilité?
j'ai pensé que je pourrais adapter mes migrations pour ajouter des choses comme les valeurs par défaut de colonne mais cela ne fonctionne souvent pas car la Doctrine remarquera la divergence entre le schéma et le code sur la prochaine diff et piétiner sur vos changements.
3 réponses
lorsque vous utilisez le schema-tool , aucun historique de modification de la base de données n'est conservé, et dans un environnement de production/mise en scène, c'est un gros inconvénient.
supposons que vous avez une structure de base de données compliquée dans un projet en direct. Et dans la prochaine révision, vous devez modifier la base de données de quelque sorte. Par exemple, les téléphones de contact de vos utilisateurs doivent être stockés dans un format différent, pas un VARCHAR , mais trois SMALLINT colonnes pour le code de pays, le code régional et le numéro de téléphone.
Eh bien, ce n'est pas si difficile de comprendre une requête qui récupérerait les données actuelles, les séparer en trois valeurs et les insérer en arrière. C'est alors que les migrations entrent en jeu: vous pouvez créer vos nouveaux champs, puis effectuer les transformations et finalement laisser tomber le champ qui détenait les données auparavant.
et encore plus! Vous pouvez même décrire le processus en arrière (la migration down ), quand vous devez annuler les changements introduit dans votre migration. Supposons que quelqu'un quelque part s'est fortement appuyé sur le format du champ VARCHAR , et maintenant que vous avez changé la structure, son morceau de code ne fonctionne pas comme prévu. Donc, vous lancez migration:down , et tout est inversé. Dans ce cas précis, il vous suffit de ramener l'ancienne colonne VARCHAR et de concaténer les valeurs, puis de laisser tomber les champs.
L'outil de migration de la Doctrine fait essentiellement la plupart du travail pour vous. Quand vous différenciez votre schéma, il génère tous les nécessaires up 's et down 's, ainsi la seule chose que vous aurez à faire est de gérer les données qui pourraient être endommagés lorsque la migration est appliquée.
aussi, les migrations sont quelque chose qui donne aux autres développeurs de votre équipe des connaissances sur le moment où il est temps de mettre à jour leurs schémas. Avec juste le schema-tool , vos coéquipiers devraient courir doctrine:schema:update à chaque fois qu'ils tirent, parce qu'ils ne sauraient pas si le schéma a vraiment changé.
lorsque vous utilisez migrations, vous voyez toujours qu'il y a des mises à jour dans le dossier migrations, ce qui signifie que vous devez mettre à jour votre schéma.
je pense que vous avez en effet 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 que mettre à jour les tables. Il n'y a pas de journal de bord pour revenir en arrière en cas de panne avec des données déjà enregistrées dans ces tableaux. Je ne sais pas exactement, mais une migration ne sauvegarde-t-elle pas aussi les données de la table correspondante qui est mise à jour? Qui serait essentiel à mon avis, sinon il y est pas de grande raison de les utiliser.
donc oui, je pense personnellement que la raison principale pour utiliser les migrations dans un environnement de production est la sécurité et peut-être un peu de flexibilité. La sécurité serait la gagnante ici je pense :)
Espérons que cette aide.
edit: Voici une autre réponse avec des références à l'Symfony-docs: Est-il sécuritaire d'utiliser doctrine2 migrations dans l'environnement de production avec symfony2 et php
vous ne pouvez pas non plus effectuer de grandes mises à jour avec la migration de doctrine simple. Comme essayer de mettre à jour l'index sur la base de données des utilisateurs de 30 mln. Comme il sera beaucoup de temps alors que votre application ne sera pas accessible.