ワシはワシが育てる

週刊少年ジャンプと任天堂のゲームが三度のメシより好きです。

Railsのmigrationの扱い方

Railsでデータベーススキーマを定義するmigrationはアプリケーションを作り始めた当初こそ便利ですが、継続的に開発してくると扱いに困ることがしばしばあります。

既存のテーブル構造を変更する度に逐一定義ファイルを作成していると、気づけばmigrationフォルダがファイルの山になり、開くだけでゾッとするでしょう。

他にもハマりどころはあるのですが、例えば「rails g model user」コマンドでモデルを作成すると自動的に「create_users.rb」というマイグレーションファイルが生成されます。
しばらくしてuserモデルを削除したいと思い「rails d model user」コマンドを打つと、これまた自動で「create_users.rb」が削除されています。

しかしuserモデルを削除しただけでは既存のデータベースにまだusersテーブルが残っているので、次のmigrationで「drop_table :users」と定義しなければなりません。
するとまた別環境で最初からマイグレーションを実行すると、usersテーブルは元々存在しないので、「drop_table :users」でエラーが発生してしまいます。

つまり既存のテーブルを途中で削除するとマイグレーションエラーが発生してしまう、ということです。

もちろん回避する方法はあり

if ActiveRecord::Base.connection.table_exists? 'users'
  drop_table :users 
end

というようにテーブルが存在することを確認すればよいのですが、こういったイレギュラーな書き方は得てしてエラーの元なので注意が必要です。

開発者それぞれ考え方が異なるかと思いますが、僕はmigrationで逐一定義しなくても良いんじゃないかと思っています。

既存のテーブルをリファクタリングしてmigrationが溢れてきた頃に、テーブル構造が全定義されているschema.rbを新しいmigrationファイルにコピペして「このバージョンではここからスタート!」みたいな感じでゆるーくやるようにしています。

そのためのschema.rbだと思うので、定期的にリセットしてしまうのもありかと思います。