Réponses:
rake db:migrate:redo VERSION=xxxxxxx, mais cela exécutera downl' upétape, puis l' étape. Vous pouvez le faire conjointement en commentant temporairement l'étape descendante.
rake -T.
db:test:preparen'apparaît pas non plus sur cette liste. Dieu, je suis en retard à la fête.
rake db:migrate:up VERSION=my_versionpeut ne rien faire , car la table schema_migrations indique toujours qu'elle a été exécutée. Dans la même situation rake db:migrate:redo VERSION=my_versionpeut échouer car il ne peut pas supprimer la table. Dans ce cas, commentez downtemporairement la méthode dans la migration et relancez-larake db:migrate:redo...
rake db:migrate:up VERSION=1234567890de même rake db:migrate:downpour réduire une migration spécifique. Vous pouvez obtenir une liste des tâches de râteau disponibles avec rake -T.
VERSIONmentionné ici est la valeur entière au début de chacun de vos fichiers de migration (qui est juste l'horodatage de sa création). Par exemple VERSION=20150720023630,.
VERSIONest juste une variable d'environnement afin qu'elle puisse venir en premier dans la commande ou même définir avant la commande:VERSION=1234567890 rake db:migrate:up
J'ai dû exécuter une seule migration qui a changé et qui devait être réexécutée indépendamment de toutes les autres migrations. Lancez la console et procédez comme suit:
>> require 'db/migrate/your_migrations.rb'
=> ["YourMigrations"]
>> YourMigrations.up
=> etc... as the migration runs
>> YourMigration.downPlus utilement, cela pourrait être mis dans une tâche de râteau, etc.
change, exécutez à la YourMigrations.migrate(:up)place (ou :downaussi!)
require "#{Rails.root}/db/migrate/your_migrations.rb"
rake db:migrate VERSION=20098252345essayez cela.
VERSIONest juste une variable d'environnement afin qu'elle puisse venir en premier dans la commande ou même être définie avant la commande:VERSION=20098252345 rake db:migrate
rake db:migrate:redo version='xxxx' N'oubliez pas de mettre entre guillemets xxxx, xxxx est l'horodatage (ou ID de migration) de votre migration.
Vous pouvez vérifier les horodatages (ID de migration) pour les migrations précédentes que vous avez effectuées en utilisant
rake db:migrate:status L'élargissement de la réponse par korch ci-dessus requiren'a pas fonctionné pour moi, mais loada fonctionné. Pour être concret, pour le fichier de migration:
class ChangeMinQuantityToRaces < ActiveRecord::Migration
def change
change_column :races, :min_quantity, :integer, :default => 0
end
enddans la console en tapant
> load 'db/migrate/30130925110821_change_min_quantity_to_races.rb'
> ChangeMinQuantityToRaces.new.changetravaillé pour moi.
> Race.new.min_quantity # => 0 C'était pour ruby 1.9.3p484 (2013-11-22 révision 43786) [x86_64-linux] et Rails 3.2.13.
Ajout de mes 2 ¢ à cela parce que j'ai rencontré le même problème:
Si vous souhaitez absolument réexécuter une migration sans en créer une nouvelle, vous pouvez effectuer les opérations suivantes:
rails dbconsole -p
devdb=# delete from public.schema_migrations where version = '20150105181157';
Et les rails «oublieront» qu'il a exécuté la migration pour 20150105181157. Maintenant, lorsque vous exécutez db: migrate, il l'exécutera à nouveau.
C'est presque toujours une mauvaise idée. Le seul cas où cela pourrait avoir du sens est si vous avez une branche de développement et que vous n'avez pas encore étoffé votre migration et que vous souhaitez y ajouter des éléments en développement. Mais même dans ce cas, il est préférable d'effectuer votre migration dans les deux sens afin de pouvoir correctement revenir en arrière et réessayer à plusieurs reprises.
Il doit y avoir un moyen d'exécuter la classe de migration via la console. Je n'arrive pas à faire reconnaître le code des migrations.
Cependant, comme l'indiquent les commentaires, il est préférable d'exécuter les migrations dans l'ordre. Utilisation:
rake db:migrate VERSION=##########Copiez et collez votre code dans la migration vers le script / la console?
J'ai une méthode utilitaire qui facilite le développement. Je trouve que cela m'aide à éviter de créer trop de migrations - normalement je modifie les migrations jusqu'à ce qu'elles aient été déployées.
http://fullware.net/index.php/2011/05/26/easily-load-rails-migrations-for-console-execution/
J'utilise cette technique en développement lorsque je modifie une migration de manière significative, et je ne veux pas migrer d'une tonne et perdre des données en cours de route (surtout lorsque j'importe des données héritées qui prennent beaucoup de temps. Je ne veux pas avoir à réimporter à nouveau).
C'est 100% hackish et je ne recommanderais certainement pas de le faire en production, mais cela fera l'affaire:
STEP=nargument àdb:migrate(oùnest le nombre de migrations à exécuter, comme il y en a pourdb:rollback) - alors vous pouvez fairerake db:migrate STEP=1ourake db:migrate STEP=2, etc.