既存のマイグレーションに存在チェックをいれたい

Question

Rails で開発していてブランチを切り替えたときに毎回マイグレーションが実行されてしまい
すでに存在している create_table や add_column がエラーになるので
マイグレーションディレクトリを消して対処してるんですが
これを回避するにはどうするのがいいのでしょうか

マイグレーションは数百にのぼるのですべての
add_column, create_table の前に存在チェックしてスキップコードをいれるのは大変で

add_column, create_table を存在する場合にスキップするようにオーバーライドしたモジュールかクラスを作って

class xxx < MyMigration

とか

class xxx < ActiveRecord::Migration
include CheckedMigration

と１行ずつはさんでいくならなんとか手作業でもできるかなという感じなんですが
この２つだとどちらのほうがいいでしょうか

あるいはもっと簡単に行うことはできますか？

Comments

[maisumakun]

「ブランチを切り替えたときに毎回マイグレーションが実行されてしま」うこと自体遭遇したことがないのですが、マイグレーションやschema.rbもきちんとGit管理していますか？

[maisumakun]

（バグって重複登録されたので片方を削除）

[退会済みユーザー]

schema を commit に含めてしまうと今度は他の人がマイグレーションをするべきなのにされなくなってしまうので schema は毎回リセットされます　複数人で開発している場合 Rails の develop の状況と個々人がローカルでもってる MySQL の状態がどうしても違ってしまうので…

[maisumakun]

そういう状況であれば、マイグレーションでなくridgepole（https://github.com/winebarrel/ridgepole）などで管理するほうがいいかもしれません。

Answer 1

##　方法論として

そのどちらも、新しいMigrationを追加したときに忘れると思います
よって初期化あたりで、ActiveRecord::Migration 自体を上書き拡張する方法もあります
ただし本番で本当に不正なmigrateが動くときに気づかないのは問題なので開発限定にすべきでしょう

config/initializers/develop_checked_migration.rb

if Rails.env.development?
  ActiveRecord::Migration.send(:prepend, Module.new do
    def create_table(*args)
　　　## 既存があればスキップ
     super 
    end
  end)
end

そもそもMigrationが動くのが間違い

db/20170921042237_create_hoges.rb という migration ファイルが有った場合に
schema_migrations テーブルに 20170921042237 というデータがあればその migrationは動きません

これは Railsのデフォルト 機能であり、ブランチ切り替えで動くならRailsのレールを外れる何かをしていませんか？
例えば、ブランチ切り替えて、開発データを作り直す際に schema_migrations まで消してしまうとか
もしくは、日付ではなく自前の連番を付けて、ブランチごとに並び替えが多発しているとか

一番良いのは、そのような発生原因を潰すべきだと思います

Comments

[退会済みユーザー]

リポジトリに schema はコミットしないルールなので新しいブランチを develop からきると必ず空になって全マイグレーションが実行されます
schema をコミットすると誰か一人の環境でしかそのマイグレーションが実行されず今度はいつのまにか追加されたカラムが他の人のローカル環境（ステージング、本番でも）反映されないことになりませんか？
チーム開発の場合この問題をどうやって解決しているのでしょうか

[Ighrs]

schema.rb ではなく、データベースにRailsが勝手に作る schema_migrationsテーブルのことです

[Ighrs]

また、いつの間にか他人が追加したファイルでもタイムスタンプ（201709****）が schema_migrations テーブルのデータになければそれだけが実行されるので問題ないですね

本番に反映されない云々は schema.rb ではなく他人適用後または本番展開後の古いMigrationファイルを修正したら発生します
チーム開発ルールとしては「master/develop」にマージされたMigrationファイルの修正は禁止、修正があれば修正Migrationファイルを追加する
だと思います

[退会済みユーザー]

マイグレーションをどこまで実行したかはMySQL自体にかかれているのですね…
コミットの中にはいっているものかと思っていました…
ということはマイグレーションが発生するのはブランチの切り替えのせいじゃなく
新しくタスクをはじめるときによく mysql のダンプを流し込んでいるせいでマイグレーションが起こってるのかも
ただステージングや本番で入ってくる新しいデータで動作確認するのは必要なことなので
テーブルごとにデータを流し込むのも大変で…やはりデータが存在しても再実行できるようにテーブルチェックは必要になる気がします…

[退会済みユーザー]

initializer でマイグレーションにモジュールをっくつけてオーバーライドする書き方すごく勉強になりました
マイグレーションファイルは一切かきかえなくてもいいんですね…