Beaucoup de gens parlent de migrations de DB, en particulier de sa possibilité de restauration.
Je doute, que ce soit utile du tout, car le schéma de DB et le modèle sont étroitement liés à la logique d'application (MVC).
Supposons que j'ai fini de rentabiliser de certaines migrations. Et quoi ? L'application ne fonctionnera pas, car sa logique s'appuie pleinement sur la DB.
Quels sont les cas d'utilisation de la capacité de restauration des migrations de dB?
la question principale
Pourquoi la restauration est présentée comme une fonctionnalité, lorsque je dois changer le code?
i ne pas crée les migrations, comme "add_another_field_to_table". Au lieu de cela, chaque fichier de migration décrit complètement chaque table dans dB. Quand j'ai besoin de changer quelque chose dans ma dB, je change simplement le fichier de migration, mais ne le roule pas .
Vraiment, si je retourne la migration,
6 Réponses :
Le point de restauration est que vous retournez le code de restauration et DB en même temps. Le scénario est que vous mettez à niveau votre code et votre DB sur votre serveur de production, vous trouverez un bogue et vous devez vraiment revenir en arrière. Donc, retournez votre code et utilisez votre migration en bas pour faire rouler votre dB.
Ne comprend pas vraiment votre problème, mais j'essaie d'expliquer un peu le retour. Vous faites Rollback si vous souhaitez annuler les changements de la migration respective. Cela signifie que la base de données sera modifiée et que votre schema.rb sera automatiquement régénéré. Lorsque vous faites cela, vous souhaitez également supprimer le code de référencement également. Par exemple, si vous avez supprimé un champ du modèle, vous ne souhaitez probablement pas vous référer à cet attribut dans votre code. Si vous essayez d'accéder, vous allez ensuite vous donnera une exception d'attribut indéfinie. C'est ça. Peut devenir un peu lourd à la restauration par exemple si vous avez créé des migrations de modèle 10 avant et que vous souhaitez modifier certains champs. Il est préférable de créer une nouvelle migration et de les modifier, au lieu de revenir à la migration correspondante.
Lisez votre mise à jour et je pense que vous n'utilisez pas l'avantage principal des migrations, la flexibilité.
Mais votre solution donne plus de vue d'ensemble de la situation de la base de données. Si vous aimez faire cela, je suggère les étapes suivantes dans l'ordre.
Cette fonctionnalité n'affecte pas vos modèles ni quelque chose, modifie simplement le fichier de migration, régénère votre schema.rb et modifie la structure de la base de données, rien d'autre. Ne peut pas faire de code Rollback comme avec le système de contrôle de la version et n'a pas vraiment de sens de faire quelque chose comme ça. Vous devez veiller à ne pas utiliser de champs supprimés. Rails a automatisé la mappage entre champs de base de données et attibutes, par exemple si vous avez un
Rake DB: Migrer la version = xxx , j'aime mieux Rake DB: Rollback Step = 2 Par exemple, Rolls Back 2 migrations , étape en option)
Rake DB: migrer )
user_id dans votre table de la table , vous pouvez l'appeler comme attribut dans votre modèle, commentaires_instance.user_id .
Je pense qu'un compromis, quelles sont les migrations. Ils préservent les données dans la DB de Production Server. Je peux faire de petites modifications sans toucher les données dans les autres tables. Ai-je raison ?
Eh bien, si vous utilisez vos migrations comme vous le faites, vous devez également faire ces 3 étapes de votre mode de production (l'étape 1,3 est correcte), mais c'est un peu hacky, c'est pourquoi vous utilisez de nouvelles migrations lors de la modification de la DB, annuler ce piratage également lors de la mise à jour de vos modifications en mode de production. Quoi qu'il en soit, vous n'avez pas besoin d'utiliser vos migrations comme vous le faites à cause de l'organisation, les champs de votre table peuvent être dans différentes migrations, vous ne vous perdez pas à cause de schema.rb. Si vous avez besoin de la structure de la table, vous pouvez obtenir de là.
Comment gérez-vous cela? Vous devez ajouter une colonne à vos tables de développement, le code de test, la mise à jour du site en direct sans oublier de mettre à jour la DB en direct en même temps (COS si vous le faites, il y aura de grandes erreurs) et à la remember pour préserver les données en direct existantes. Cet aspect de la gestion de la DB peut être une véritable douleur sans une belle solution gérée comme des rails.
SO ...
Maintenant votre prêt à libérer de la production ....
Bien sûr, avec vous en ajoutant une colonne, ce n'est pas si déroutant de le faire vous-même.
Mais que se passe-t-il s'il y avait 3 programmeurs ajout de migrations? Et si vous avez de nombreux sites en direct, tous dans différentes versions? Est-ce que ce site en direct 2 ou 17 migrations? Qu'est-ce que je dois faire pour obtenir le DB jusqu'au dernier code, tout en préservant les données en direct? Pouvez-vous voir comment cela se déroulerait très rapidement de gérer?
Rails Migrations (et pratiquement tous les systèmes de migration fonctionnent sur les mêmes principes) sont conçus pour rendre la mise à jour des structures de DB vraiment faciles. Vaut la peine d'être utilisé correctement.
Considérez un scénario où vous utilisez Capistrano pour déployer votre site et créer des instantanés temporels de chaque déploiement. Utilisation de l'horodatage sur le dossier et vos migrations, vous pouvez identifier les versions du code et du schéma aller de pair et effectuer une restauration.
Un référentiel git vous donnerait des options similaires.
Bien entendu, le problème réel est que, une fois que les utilisateurs d'un site commencent à ajouter des données, qui seront potentiellement purgés, à moins que vous ne le récupériez avant une restauration et la restaurée de manière minutieuse à une date ultérieure.
J'ai trouvé que les retournements ne sont utiles que si elles sont faites localement, c'est-à-dire pendant que vous travaillez sur un nouveau bit de code. Une fois qu'une migration s'est engagée dans votre système de contrôle de la version, si vous réalisez qu'il y avait une erreur, il ne fonctionne pas vraiment pour rétrécir la migration, car d'autres développeurs auront tiré la migration vers le bas et l'exécuter, de sorte que vous auriez donc besoin de Dites-leur de renvoyer également - ceci est trop difficile à gérer et vous fait aussi regarder incompétent :)
Mieux encore dans cette situation pour simplement faire une autre migration pour résoudre le problème, tout le monde (y compris votre serveur de production) colle avec le système Tir & Migrate.
Je conviens que cela semble être le cas d'utilisation le plus courant. Comme l'OP, je ne vois pas le bénéfice réel d'une procédure de restauration de la DB majeure. La plupart des mises à jour sèche saines sont non destructives par design précisément parce que le logiciel de production ne doit pas casser lorsque les mises à jour sont appliquées. Par conséquent, même si vous devez remplir le code de production, vous pouvez souvent conserver le schéma mis à jour, puis appliquez simplement quelques migrations supplémentaires, si nécessaire, plutôt que de reposer en arrière et de réappliquer une version modifiée de la migration d'origine.
J'utilise la restauration de migration localement avec Rake DB: migrer: Redo tout en travaillant sur le code de migration et avant la finale de commit.
"Je ne crée pas les migrations, comme" add_another_field_to_table ". Au lieu de cela, chaque fichier de migration décrit complètement chaque table dans dB. Quand j'ai besoin de changer quelque chose dans ma dB, je peux simplement modifier le fichier de migration" Pouvez-vous expliquer cela plus loin, parce que cela me semble très étrange. Lorsque vous devez ajouter une colonne, vous ne faites pas une nouvelle migration, mais au lieu de cela, vous modifiez une vieille migration? On dirait que vous n'utilisez pas correctement les migrations ...
Oui, ça me semble aussi. Je n'ai pas remarqué des avantages des migrations partielles. Ils brillent juste la grande image de ce qui se passe avec les migrations en ce moment. Je sais que ce fichier schema.rb est juste pour cela. Mais, les migrations partielles ralentissent mon travail, car lorsque je dois examiner une table dans DB, je dois passer à plusieurs fichiers de migration "add_column_to_table". Mais, quels sont les avantages réels de ceux-ci? Je ne connais pas encore la réponse ...