読者です 読者をやめる 読者になる 読者になる

猫の魔法

主にruby系の技術メモを記載

個人的メモ:Rails AntiPatterns(19)

Solution: Never Use External Code in a Migration

  • migrationをする際にDB上のデータを一緒に変更する事はよくある事だが、upメソッド内にrubyでその手順を直接書くべきではない
  • 理由はパフォーマンスと、DBから見た外部依存性がrails側にできてしまう為で、このような場合はupメッソド内に生のSQLを書けないかを検討する。

  • もしrubyのコードにmigrationの内容を書く必要があるなら、モデル間の依存性をすべて移行用クラスの中に記載する。

    • 例えばUserがhas_manyでJobを持っているのであれば、下記のように依存関係自体をモデルではなくmigrationスクリプトの中に内包する(以下コード抜粋)
class AddJobsCountToUser < ActiveRecord::Migration
  class Job < ActiveRecord::Base 
  end 
  class User < ActiveRecord::Base 
     has_many :jobs 
  end
  def self.up 
    add_column :users, :jobs_count, :integer, :default => 0
    User.reset_column_information 
    Users.all.each do |user| 
       user.jobs_count = user.jobs.size user.save 
    end
  end 
  def self.down 
    remove_column :users, :jobs_count 
  end 
end
  • ★つまりmodelの最新版とmigration時点でのDBの状態は必ずしも一致しないので、マイグレーション時に想定されている依存性を記載した方がいいということ。

  • User.reset_column_informationはこれが呼ばれた時点のDBの内容を読み込み、それをActiveRecodeに反映させる。

Solution: Always Provide a down Method in Migrations

  • 不可逆なmigrationを行う場合はActiveRecord::IrreversibleMigration例外をdownメソッドのなかで発生させることで、開発者に手動でのDB修正が必要な事を知らせるようにする。

AntiPattern: Wet Validationsの手前まで読了

関連

個人的メモ:Rails AntiPatterns(一覧) - 猫の魔法