0

順番に実行されるレーキタスクのバッチがあります。

task :batch_tasks => :environment do
  Rake::Task["db:drop"].execute
  Rake::Task["db:create"].execute
  Rake::Task["db:migrate"].execute
  Rake::Task["db:seed"].execute
  Rake::Task["db:test:prepare"].execute
  Rake::Task["custom_task_1"].execute
end

custom_task_1の内容は次のとおりです。

task :custom_task_1 => :environment do
  puts "begin custom task"
  orders = Order.all #three records
  orders.each do |order|
    puts "Do something to Order\n"
  end
  puts "end custom task"
end

上記のバッチプロセスを実行すると、次のようになります。

rake batch_tasks
begin custom task
end custom task

しかし、バッチプロセスの後にカスタムタスクを実行すると、次のようになります。

rake custom_task_1
begin custom task
Do something to Order
Do something to Order
Do something to Order
end custom task

rake batch_tasks注意すべき点の1つは、の後にブレークポイントを指定してデバッガーを実行するとrake db:seed、チェックオンeval Order.allすると空の配列が返されること[]です。ただし、すべてのレーキタスクが終了した直後にOrder.allデータがあります。

rake db：seedについて何が欠けていて、次のタスクでActiveRecordデータにアクセスできるのですか？

4

2 に答える 2

1

muは短すぎるため、移行でモデルを使用する前にモデルをリロードする必要があります。これは、すべてのrakeタスクが共通の環境で実行されるためです。つまり、レールを1回だけロードします。そのため、テーブル定義はすでに確立されている場合があります。おそらくreset_column_information、新しい値をロードするためにを使用する必要があります。

または、実行している一連のタスクは、独立して実行する必要があるように見えます。これは、capistranoまたはthorの優れたユースケースになる可能性があります。

于 2012-09-11T02:36:06.010 に答える
0

したがって、簡単な修正は、db:test:prepare行をバッチの最後に移動することでした。

この問題は、環境がに切り替えられ、カスタムタスクが最後の環境で実行されていたことが原因であると考えられdevelopmentますtest。最後の環境では、テストデータベースが空になっています。

このdb:seedコマンドはおそらく環境をdevに戻し、カスタムタスクは正しいデータベースに対して実行されます。

task :batch_tasks => :environment do
  Rake::Task["db:drop"].execute
  Rake::Task["db:create"].execute
  Rake::Task["db:migrate"].execute
  Rake::Task["db:seed"].execute
  Rake::Task["custom_task_1"].execute
  Rake::Task["db:test:prepare"].execute # <-- Moved after all other tasks
end
于 2012-09-11T03:37:40.250 に答える