rake db: schéma: chargement vs migrations

171

Question très simple ici - si les migrations peuvent devenir lentes et fastidieuses à mesure qu'une application devient plus complexe et si nous avons le plus propre rake db:schema:loadà appeler à la place, pourquoi les migrations existent-elles?

Si la réponse à ce qui précède est que les migrations sont utilisées pour le contrôle de version (un enregistrement pas à pas des modifications apportées à la base de données), alors qu'une application devient plus complexe et rake db:schema:loadest davantage utilisée à la place, continuent-elles à conserver leur fonction principale?

Mise en garde:

D'après les réponses à cette question: rake db:schema:load supprimera les données sur un serveur de production donc soyez prudent lors de son utilisation.

ruby-on-rails ruby-on-rails-3 migration sscirrus
la source
5
+1 Je n'ai jamais compris le but des migrations; pourquoi ne pas contrôler simplement la version du schéma?
alternatif
5
@alternative - les migrations vous permettent de faire d'autres choses, comme si vous devez ajouter une colonne non nulle, vous pouvez remplir intelligemment cette colonne avec des données au lieu d'utiliser une valeur par défaut.
Josh M.

Réponses:

208

Les migrations fournissent des modifications par étapes avant et arrière à la base de données. Dans un environnement de production, des modifications incrémentielles doivent être apportées à la base de données lors des déploiements: les migrations fournissent cette fonctionnalité avec une sécurité de retour arrière. Si vous exécutez rake db:schema:loadsur un serveur de production, vous finirez par supprimer toutes vos données de production. C'est une habitude dangereuse à prendre.

Cela étant dit, je pense que c'est une pratique décente de «faire échouer» occasionnellement les migrations. Cela implique de supprimer les anciennes migrations, de les remplacer par une seule migration (très similaire à votre schema.rbfichier) et de mettre à jour le schema_migrationstableau pour refléter ce changement. Soyez très prudent en faisant cela! Vous pouvez facilement supprimer vos données de production si vous ne faites pas attention.

En passant, je crois fermement que vous ne devriez jamais mettre la création de données dans les fichiers de migration. Le seed.rbfichier peut être utilisé pour cela, ou pour des tâches de râteau ou de déploiement personnalisées. Le placer dans des fichiers de migration associe la spécification de votre schéma de base de données à vos spécifications de données et peut entraîner des conflits lors de l'exécution des fichiers de migration.

jesse reiss
la source
80
merci d'avoir informé que rake db: schema: load supprime toutes les données de production!
Magne
2
Plutôt que de remplacer les migrations «réduites» par une nouvelle qui imite le schéma, j'ai écrit un joyau qui les efface simplement et invite les utilisateurs à utiliser db:schema:loads'ils essaient de s'exécuter db:migratesur une nouvelle installation. @ clear_migrations
Yarin
probablement une réponse évidente, mais avant la première mise en production, recommanderiez-vous simplement de supprimer toutes les migrations et d'utiliser db.schema comme première migration?
dtc le
30

Je suis tombé sur ce post, il y a longtemps et je n'ai pas vu la réponse que j'attendais.

rake db:schema:loadest idéal pour la première fois que vous mettez un système en production. Après cela, vous devez exécuter les migrations normalement.

Cela vous aide également à nettoyer vos migrations quand vous le souhaitez, car le schéma contient toutes les informations pour mettre d'autres machines en production, même lorsque vous avez nettoyé vos migrations.

ereslibre
la source
Vous pouvez donc "nettoyer" vos migrations car vous n'avez jamais à les utiliser? Cela ressemble à une déclaration bizarre.
Abe Petrillo
Je ne sais pas quel est l'avantage d' db:schema:loadautre que de se raser quelques secondes une fois tout au long du cycle de développement. Avez-vous déjà travaillé avec une application dont la création a pris plus de 30 secondes? Je travaille actuellement sur une application qui a des bogues dans ses fichiers de migration et elle ne migrera jamais sans avoir de corrections de bogues ou en cours d'exécution, db:schema:loadce qui me fait penser au schéma: la charge est pour quand quelque chose a mal tourné concernant le développement de l'application.
Ninjaxor
Un autre argument que je ferais pour conserver les migrations est que l'équipe principale de rails dirige les utilisateurs instead of editing schema.rb, please use the migrations feature. Ainsi, si vous exécutez db:schema:loadsur un fichier généré automatiquement que vous n'avez pas de migrations à générer automatiquement à nouveau, vous vous engagez dans la voie de la "modification" manuelle du schéma et de la suppression des migrations. J'aurais aimé avoir une citation du guide des rails à ce sujet, mais ils ne parlent pas de schema: load, ce qui ajoute à ma frustration en décidant comment aborder le schéma: load feature. = /
Ninjaxor
Je suis venu sur cette page précisément parce que je suis d'accord avec cela. Mon expérience est qu'une fois le site en production, il est beaucoup plus sûr d'utiliser les migrations pour le changer. Malgré cela, les commentaires du début de db / schema.rb indiquent précisément le contraire! (J'ai le problème au début de chaque projet car j'ai oublié de mettre db / schema.rb dans le .gitignore ...)
user1251840
@AbePetrillo wow j'ai complètement manqué ce commentaire. Bien sûr que non, ce que je voulais dire, c'est que vous pouvez nettoyer les anciennes migrations qui ont été exécutées sur toutes les machines de production si vous le souhaitez. Au fil des ans, je les ai toujours gardés, mais ma déclaration «vous aide à nettoyer vos migrations quand vous le souhaitez» ne signifiait pas que «je n'aurais jamais à utiliser les migrations». Ainsi, lorsque vous déployez une nouvelle machine, exécutez rake db:schema:loadplutôt que rake db:migrate. Ensuite, à partir de là, vous pouvez rake db:migrate.
ereslibre
9

Les migrations vous permettent également d'ajouter des données à la base de données. mais db: schema: load ne charge que le schéma.

Shaunak
la source
6

Parce que les migrations peuvent être annulées et fournir des fonctionnalités supplémentaires. Par exemple, si vous devez modifier certaines données dans le cadre d'un changement de schéma, vous devrez le faire en tant que migration.

Jamie Penney
la source
4

En tant qu'utilisateur d'autres ORM, il m'a toujours semblé étrange que Rails n'ait pas de fonction de synchronisation et de mise à jour. c'est-à-dire, en utilisant le fichier de schéma (qui représente le schéma entier et à jour), parcourez la structure de base de données existante et ajoutez / supprimez des tables, des colonnes et des index selon les besoins.

Pour moi, ce serait beaucoup plus robuste, même si peut-être un peu plus lent.

Dan James
la source
1
La tâche de migrer une base de données avec des données d'un schéma compliqué à un autre n'est parfois pas anodine. Il peut ne pas être résolu automatiquement et les données peuvent ne pas être migrées de manière cohérente en une seule étape. La migration des rails est maître et le schéma dépend. Schéma recréé automatiquement à chaque migration mais pas l'inverse.
oklas
Les guides propres à Rails indiquent explicitement qu'il schemas'agit du maître et non des migrations.
Drenmi
0

J'ai déjà publié un commentaire, mais je pense qu'il est préférable de mettre les commentaires du fichier db / schema.rb ici:

# Note that this schema.rb definition is the authoritative source for your
# database schema. If you need to create the application database on another
# system, you should be using db:schema:load, not running all the migrations
# from scratch. The latter is a flawed and unsustainable approach (the more migrations
# you'll amass, the slower it'll run and the greater likelihood for issues).
#
# It's strongly recommended that you check this file into your version control system.

En fait, mon expérience est qu'il est préférable de mettre les fichiers de migration dans git et non dans le fichier schema.rb ...

user1251840
la source
0

rake db:migrateconfigurer les tables de la base de données. Lorsque vous exécutez la commande de migration, elle cherchera dans db / migrate / tous les fichiers ruby ​​et les exécutera en commençant par le plus ancien. Il y a un horodatage au début de chaque nom de fichier de migration.

Contrairement à rake db:migratecela, exécute les migrations qui ne sont pas encore exécutées, rake db:schema:loadcharge le schéma déjà généré db/schema.rbdans la base de données.

Vous pouvez en savoir plus sur les commandes de la base de données rake ici .

Nesha Zoric
la source