Rebase les migrations Rails dans un projet de longue durée

Question

Dans lequel je veux dire "rebasage" dans le dictionnaire, plutôt que de git définition...

J'ai une grande, longue, Rails de projet qui a environ 250 migrations, il se fait un toucher lourd à gérer tous ces.

Cela dit, j'ai besoin d'une base à partir de laquelle de purge et de reconstruire ma base de données lors de l'exécution des tests. Ainsi, les données contenues dans les présentes est important.

Ce que quelqu'un a des stratégies pour dire, dumping, le schéma à un point d'archivage de toutes les anciennes migrations et de repartir avec de nouvelles migrations.

Évidemment, je peux utiliser le râteau schéma:dump - mais vraiment j'ai besoin d'une manière db:migrate va charger le schéma d'abord, puis commencer à courir le reste de la migration.

Je voudrais continuer à utiliser les migrations comme ils sont très utiles dans le développement, cependant, il n'y a aucun moyen que je vais retourner et l'édition d'une migration à partir de 2007, de sorte qu'il semble idiot de le garder.

Answer 1

En général, vous n'avez pas besoin de nettoyer les anciens migrations. Si vous êtes en cours d'exécution db:migrate à partir de zéro (pas de base de données existante), Rails utilise db/schema.rb pour créer les tables au lieu de courir à chaque migration. Sinon, il ne fonctionne que les migrations nécessaires à la mise à niveau de l'actuel schéma de la dernière.

Si vous souhaitez combiner des migrations jusqu'à un point donné en un seul, vous pouvez essayer de:

• migrer à partir de zéro jusqu'à l'objectif du schéma à l'aide de rake db:migrate VERSION=xxx
• dump le schéma à l'aide de rake db:schema:dump
• supprimer les migrations depuis le début jusqu'à la version xxx et de créer une seule nouvelle migration à l'aide du contenu de db/schema.rb (mis create_table et add_index états dans l'auto.méthode de la nouvelle migration).

Assurez-vous de sélectionner l'un des anciens de la migration des numéros de version pour votre agrégées de la nouvelle migration; sinon, Rails de pourrait essayer d'appliquer la migration sur votre serveur de production (qui d'effacer vos données existantes, depuis la create_table instructions d'utilisation :force⇒true).

De toute façon, je ne vous recommande pas de le faire depuis des Rails s'occupe habituellement de migrations bien lui-même. Mais si vous voulez, assurez-vous de faire tout et d'essayer localement d'abord avant de vous le risque de perte de données sur votre serveur de production.

Answer 2

En plus de la réponse fournie (qui indique bien comment consolider votre volume de migrations), vous indiquez un sujet de préoccupation pour purger les données (ce qui je suppose est ajouté manuellement après luminaires remplir vos tables); ce qui implique que vous êtes en fonction sur l'actualisation d'un premier état des données. Certains projets, en effet, besoin de cours intensifs de raffinement de la base de données, de reconstruction et de re-population de tables. La nôtre dépend fortement répétitif de l'exécution de ces opérations, et j'ai trouvé que si vous pouvez réduire votre schéma entièrement à exécuter des instructions SQL, vos tables se reconstruire loin, plus vite qu'ils le seront à partir de syntaxe Ruby.

Un trivial poursuite de l'aide à la reconstruction de vos tables est de consacrer une fenêtre de terminal séparée pour un combiné unique commandement de la déclaration:

rake db:abandon de la db:create db:schéma:charge db:fixtures:load

Chaque fois que vous avez besoin de reconstruire et de le re-remplir vos tables, une flèche vers le haut, et le retour de pression de touche obtiendrez que la routine de travail. Si il n'y a pas de conflit dans SQL exécuter des instructions, et si vous n'avez pas migrations à exécuter pendant que vous êtes à projet est en cours de développement de l'état, les instructions SQL execute peut-être mieux que deux fois plus rapide que la syntaxe Ruby. Nos tables de reconstruire et de le re-remplir, dans les 20 secondes de cette façon, par exemple, alors que la syntaxe Ruby augmente le processus à plus de 50 secondes. Si vous êtes en attente sur les données à actualiser pour effectuer d'autres travaux (notamment de nombreuses fois), ce qui fait une énorme différence dans le flux de travail.