Railsのマイグレーションについては下記の記事でも少し解説させて頂きました。
【Ruby on Rails】の「O/Rマッパー」である「ActiveRecord（アクティブレコード）」、Scaffoldingで雛形アプリ作成まで
マイグレーションの実行や取り消しにはマイグレーションファイルに書かれた操作を適用する必要があります。
そもそもマイグレーションファイルとは？
RailsにおいてDBへの変更を複数の開発者がストレスなくシェアすることを目的とする仕組みです。
基本的には過去のマイグレーションファイルはいじってはいけない。
例えば、新しいモデルを作成してその後カラムを追加したいとなったとしても過去のモデルを作成するマイグレーションファイルに追加すると言ったことは基本的にしてはいけないです。マイグレーションの思想としてはファイル自体の美しさというよりも過去の履歴をしっかり管理することにあるのです。
マイグレーションファイルが多くなってきたら
マイグレーションファイルは過去の履歴を積み重ねるので多くなってきます。マイグレーションを当てるのに時間がかかったりコードを探し辛くなるというデメリットがあるのでSquasherというgemを使って複数ファイルを集約することを検討しましょう。
マイグレーションのバージョンは管理されている
1つのマイグレーションファイルが1つのバージョンとして扱われます。マイグレーションを適用すればDBスキーマのバージョンを一つあげることができ、適用ずみのマイグレーションを一つ取り消すことでバージョンを一つ下げることができます。
これはRailsのデータベース内に作成される「schema_migrations」というテーブルを通じてどのマイグレーション（バージョン）が適用されているかのデータが保存されます。
rails db:migrate
バージョンを上げる際のコマンドです。「rails migrateコマンド」は仮に適用していないマイグレーションがあった場合も適用されていないマイグレーションだけ選んで適用してれます。
rails db:rollback
一つバージョンを下げる際のコマンドです。
rails db:rollback STEP=N
回数を指定してN個前のバージョンを下げる際のコマンドです。
rails db:reset
全てキャンセルします。
rails db:migrate:reset
全てキャンセルして、新たにマイグレーションをし直します。
マイグレーションのリリース時の注意
マイグレーションをリポジトリに入れる際は、バージョンアップだけでなくロールバックもできることを確認して入れるようにしましょう。
- 「rails db:migrate」で自分の書いたマイグレーションが期待通り動作するかチェックする。
- 「rails db:migrate:redo」で自分の書いたマイグレーションがバージョンを下げる際にトラブルが発生しないか確認する。
rails db:migrate:redo
バージョンを下げた後にもう一度上げてくれるので、バージョンを戻す処理が想定どおりに動作しているかを簡単に確認することができます。実行後は手元の環境は最新の環境になっているので問題ないことを確認次第すぐに次の工程に移ることができます。
マイグレーションは環境ごとに適用する必要がある
マイグレーションコマンドは下記になりますが、この場合は開発用DBに対してマイグレーションが適用されます。
|
1 |
rails db:migrate |
それぞれの環境で適用させたい場合は下記のように指定します。
本番環境
|
1 |
rails db:migrate RAILS_ENV=production |
テスト環境
|
1 |
rails db:migrate RAILS_ENV=test |
サーバー上で直接DBをいじった場合
緊急時とかにはDBを直接操作することもあるかもしれません。（カラムにインデックスを加える等）、その場合は後からでも良いので必ずその作業に対応するマイグレーションファイルを作成するようにしましょう。
マイグレーションファイルの名前は一意にすること
マイグレーションファイルの名前はアプリ内で一意にする必要があります。テーブルの新規作成は通常は一回しかないので被らないでしょうがカラムの追加等は何度も発生する可能性があるのでマイグレーションファイルの命名には気を配る必要があります。
テーブルの新規作成
Createテーブル名
カラムの追加
Addカラム名Toテーブル名
db/schema.rb
Railsのデータベース構造がマイグレーションコマンド実行時に自動出力されます。
ロールバックできないケース
マイグレーションのロールバックができないケースもあります。
- カラムを削除してしまったため元のデータに戻せないケース
対処方法
カラムはロールバックするがデータの復活は行わない。
データを用意しなくても開発上支障がない場合はこの選択肢はありです。また、支障がある場合でも仮のデータを用意すると言ったことを行う方法もありです。
ロールバックを禁止する。
ロールバック処理の中で「ActiveRecord::IrreversibleMigrationエラー」をraiseしてロールバックを禁止します。つまりDBの状態を以前の状態に戻すことを諦める場合に使用します。
ロールバックは禁止にしないが何もしない。
これは元々のデータがミスで新しいデータが正しい場合に選択する方法になります。
テーブルの作成
自動生成コマンド
モデルの生成コマンドを実行した際に自動でマイグレーションファイルも作成されます。
|
1 |
rails g model モデル名 カラム名:データ型(string等） |
マイグレーションファイルの書き方
マイグレーションファイルのメソッド
changeメソッド
テーブルの新規作成や修正をするためのメソッドです。up/downと異なりロールバックを自動で反転して行ってくれるのでロールバック処理を記述する必要がありません。（add_columnでカラムを追加した後は反転してremove_columnでカラムを削除してくれます。）
upメソッド
マイグレートした際に実行される処理です。ここに記述した内容はdownメソッドで元に戻るようにしておきます。
downメソッド
ロールバックした際に実行される処理です。upで変更したものが元に戻るようにしておきます。
changeメソッドとup/downメソッドの使い分け
- 「カラムを追加したい場合」はchangeメソッドを使用し「カラムを削除したい場合」はup/downメソッドを使います。
理由
delete_columnでカラムを削除する場合は型情報(文字か数値か不明)を保持していないので、changeメソッドでは自動で反転してカラムを追加するというロールバック処理を行うことができません。その場合はup/downメソッドを使用するようにします。
メソッドの中身
|
1 2 3 4 5 6 7 |
create_table :comments do |t| t.references :カラム1, foreign_key: true t.string :カラム2 t.text :カラム3 t.timestamps end |
t.references :カラム1, foreign_key: true
外部キーであることを示します。
下記コマンドを実行することで自動生成することができます。
|
1 |
rails g model モデル名 カラム名:references |
t.text :カラム名, null:false
ユニークキー制約
下記のように指定することで指定したカラムはユニークキー（一意制約）を設定することが可能です。
|
1 2 3 4 5 6 |
def change create_table :users do |t| 各カラムの情報 end add_index :users, :ユニークにしたいカラム名, unique: true end |
カラムの追加及び削除
自動生成コマンド
|
1 |
rails g migration マイグレーションファイル名 追加や削除するカラム:データ型 |
マイグレーションファイルの書き方
追加
|
1 2 3 |
def change add_column :モデル名(users等）, :追加するカラム名, :データ型 end |
削除
|
1 2 3 |
def change remove_column :モデル名（users等）, :削除するカラム名(admin等), :データ型（boolean等） end |
この記事へのコメントはありません。