2010-12-09 2 views

Répondre

3

Le problème principal était que nous ne connaissions pas les noms des fichiers de migration. Je le fais avec le code suivant

ActiveRecord::Migrator.migrate("vendor/plugins/#{self.id.to_s}/lib/db/migrate/", nil) 
Package::Rake.call('db:schema:dump') 

Et la classe Rake ont la méthode suivante

def call(task, options={}) 
    options[:rails_env] = Rails.env 
    args = options.map { |n,v| "#{n.to_s.upcase}='#{v}"} 
    system "rake #{task} #{args.join(' ')} --trace >> #{Rails.root}/log/rake.log &" 
end 

Espérons que cela aidera un corps avec des problèmes similaires.

1

Cela suppose la migration est statique et dans votre db/migrate répertoire lorsque le serveur d'applications commence:

Vous pouvez ajouter le répertoire des migrations à votre chemin de chargement automatique dans config/application.rb, puis exiger la migration fichier à exécuter au sein de votre contrôleur (ou dans un initialiseur de configuration):

application.rb

config.autoload_paths += %W(#{Rails.root}/db/migrate) 

your_controller.rb

require '20101209102033_some_migration_file' 
#.... 
SomeMigrationFile.up 

Je serais intéressé de savoir quel est le cas d'utilisation ici. Semble assez sauvage!

+1

Cas d'utilisation: vous souhaitez tester l'impact des index. Donc, je veux exécuter un script qui a une sous-classe de ActiveRecord :: Migration, une sous-classe de ActiveRecord :: Base (qui lie à une copie d'une table qui m'intéresse); puis exécutez la migration vers le haut, testez les performances sur une copie de la table; annuler la migration; terminé. Je modifie ensuite le script pour créer différents ensembles d'index et vérifier à nouveau. – carlosayam

+0

Je serais intéressé d'avoir un aperçu de cette recherche que vous avez faite! – jacquard

Questions connexes