productionのデータ変更処理をmigrationに書くとrails_best_practicesに怒られる。
Rails Best Practices | Isolating Seed Data
怖話のコードで言えば下記の様なもの。
# encoding: utf-8
class InsertSeedToSound < ActiveRecord::Migration
def up
Sound.create!(id: 1, name: "鳥の鳴き声")
Sound.create!(id: 2, name: "犬の鳴き声")
Sound.create!(id: 3, name: "水滴")
Sound.create!(id: 4, name: "カエルの鳴き声")
Sound.create!(id: 5, name: "ラジオのチューニング")
end
def down
Sound.delete_all
end
end僕はmigrationに書いちゃってるけどみんなさんはどうやってますか？
seed.rbに書けっていうけどrake db:seedってリエントラントに書くもの？最初の一回だけじゃないの？
それとも、productionの状態に合わせて過去のmigrationをまとめてseed.rbをそれに合わせて書きなおすみたいなことするのかな？
ちょっと周りのrubyist２名ぐらいに聞いた感じ結論が出なかったので「ふつうこうだよ」っていうのを知ってる方がいたら教えていただけるとありがたいです！（@komagata）
追記：
たとえば1年後に、その属性やメソッドの無くなったとすると、そのタイミングで一からマイグレーションすると死亡する。という感じです。
データマイグレーションをしたいときは、
1. Railsのmigrationにのるなら、直でSQLを発行する
2. データマイグレーション用の書き捨てスクリプトを作って実行、seed.rbはそれとは別で合わせる
というかんじでやっています。
ですから、示されている例は自分なら Rails Best Practices 同様、rake タスクにします。
ふつうがどうかは知りませんが、プロジェクトの後半にややこしくなると大変なので、プロジェクトごとにルールをつくるとよいと思っています。
その他に行なっているのは、seed で生成するデータは create ではなく first_or_create にして何度でも実行できるようにしています。
それから「seed に依存するマイグレーションは禁止することにしましょう」というコーディングルールを設けています。
ただmodelのvalidationが変わったときのためにmodelを
別途migrationの中で定義しなおしてますし、AR:Base.reset_column_informationを呼ぶようにしてます。
kenchanさんの例ではおそらくこれをやってないから困る
のではないかと思われます。
このあたりrails guideにのってますね。
http://guides.rubyonrails.org/migrations.html#using-models-in-your-migrations
僕もreset_column_information使うseed使わない派だったんですが、今書きなおしちゃってました・・・。Rails GuildとRails Best Practices・・・どっちのレールに乗ればインだろう・・・