ここでは、データベースにテーブルを追加する方法を学習する。
マイグレーションの仕組みは少し複雑ですが、大事な概念である。
- モデルの作成方法
- マイグレーションファイルの編集
- マイグレートの仕方
- マイグレートの修正方法
テーブルとは
テーブルとはデータの保存をする場所で、データベースの中に含まれる。
テーブルは縦横の表のように構成され、データを１件足すごとにレコード（行）が増えていく。
また、1つのレコードのそれぞれの項目のことをカラムと呼ぶ。
エクセルなどの表計算ソフトをイメージするとわかりやすい。
テーブルを作成するときの流れ
テーブルの作成は、フローが少しわかりづらいので先に確認しておく。
作成時は、ターミナルで「rails g model (モデル名)」というコマンドを実行する。
そうするとファイルが4つ作成される。
そのうち、以下の2つのファイルを使用します。残りの2つはテスト用のファイルで、TECH::MASTERの応用編で使用する。
| ファイルの種類 | ファイル名 | 役割 |
|---|---|---|
| モデルのクラスファイル | app/models/tweet.rb | 主に、tweetsテーブルから取得したデータに何らかの命令（メソッドと言います）を実行させたいときに記述するファイル。 |
| マイグレーションファイル | db/migrate/20190513083226_create_tweets.rb(*1) | テーブルの設計図。ここに必要な事項を記述して、マイグレートを実行するとテーブルが作成されます。 |
*作成日時がファイル名となる
テーブルを作成する
必要なファイルを作成する
では実際にテーブルをつくっていく。ターミナルで以下のコマンドを実行する。
$ rails g model tweet Running via Spring preloader in process 15924 invoke active_record create db/migrate/20190513083226_create_tweets.rb create app/models/tweet.rb invoke test_unit create test/models/tweet_test.rb create test/fixtures/tweets.yml
上記のようにcreateと書かれた行が4つあって、ファイルが作成されたことを確認する。
マイグレーションファイルの記述の仕方
では続いてマイグレーションファイルの記述方法を確認する。
マイグレーションファイルとは、テーブルを作成するときの設計図のことである。
その時に必ず書くのが「カラム名」と「データ型」である。
データ型というのは初めて出てきた言葉なので、どのようなものか確認しておく。
カラムのデータ型とは
データ型とは、そのカラムに格納するデータの種類を表すものである。
あらかじめ種類を定めておくことによって、おかしなデータが予期せずカラムに保存されてしまうことを防ぐことができる。
以下に主なデータ型の種類を紹介する。
| データ型 | 説明 | 用例 |
|---|---|---|
| integer | 整数 | ユーザーのidなど |
| string | 文字(255文字まで) | ユーザー名、パスワードなど |
| text | 文字(256文字以上) | 投稿文など |
| boolean | 真か偽か | 真偽フラグ |
| datetime | 日付と時刻 | 作成日時、更新日時など |
マイグレーションファイルを編集する
db/migrate/2019XXXXXXXXXX_create_tweets.rbファイルを開いて編集する。XXXXXXXXの部分には、マイグレーションファイルを作成した日時が入っている。
class CreateTweets < ActiveRecord::Migration[5.2] def change create_table :tweets do |t| t.string :name t.text :text t.text :image t.timestamps end end end
上の4~6行目の通り記述を追加する。
１行の中の前半がデータ型、後半がカラム名を表す。
4行目の前半ではstring型を指定している。
名前のカラムにそれほど長い文字列が入ることは想定されないため、255字まで格納できるstringを使っている。
また、最初に「t.」をつけているのは決まった書き方なので必ず守る。
後半では「:name」と書いてあるが、これは「name」という名称でカラムをつくるという意味である。
最初に「:（コロン）」がついていますが、これはシンボルと呼ばれるものである。
シンボルについては次の項にて後述。
カラム名の前には必ずコロンをつけるというルールさえ覚えておけばひとまずOK。
シンボルとは
任意の文字列の前にコロンをつけると、Rubyでは文字列ではなくシンボル型として扱われる。
主に処理速度を向上させるために用意されている仕組みである。
シンボル型の実態は整数のため、コンピュータにとって処理しやすい。
逆に整数が並んでいても人間にとってはわかりづらくなってしまう。
そのため、整数に対して文字列のラベルをつけたものがシンボルになる。
マイグレートを実行する
マイグレーションファイルを編集しただけではテーブルの追加はできない。
編集内容を反映させるためにマイグレートを実行してみる。
$ rails db:migrate == 20190513083226 CreateTweets: migrating ===================================== -- create_table(:tweets) -> 0.0059s == 20190513083226 CreateTweets: migrated (0.0063s) ============================
このような表示が出ればうまくいっている。
phpMyAdminを使って、詳しく内容を見てみる。
上記の手順で確認すると、tweetsテーブルの中に「name」「text」「image」カラムがきちんとできていることがわかる。
マイグレートの仕組み
今までみてきたように、マイグレーションファイルを作成してからマイグレートを実行するとテーブルに変更を反映させることができる。
では、テーブルをもう1つ追加するために同じ操作を行なったらどうなるだろうか。
上図の状態でマイグレートを実行すると、マイグレーションファイル１に対しては何も行われず、マイグレーションファイル２についてのみマイグレートが実行される。
つまり、Railsではそれぞれのマイグレーションファイルに対して、すでにマイグレート済みかどうか管理する仕組みがあるというこである。
それに伴って、取り扱いに注意が必要なポイントがある。
マイグレーションファイルを扱うときの注意点
すでにマイグレート済みのマイグレーションファイルを編集したり、削除しては絶対にいけない
設計図であるマイグレーションファイルと、実態であるデータベースの内容がずれてしまう。
応用カリキュラムでアプリをサーバーにアップデートする際に修正しにくいエラーになってしまうため、絶対に行わないようにする。
マイグレートの状況を確認する方法
マイグレート済みのファイルを誤って編集してしまわないためには、マイグレートが終わっているのかどうか確認することが必要だ。
下記のコマンドで確認することができる。
$ rails db:migrate:status
実行すると以下のような結果が表示される。
なお、以下はサンプルのため実行時に同じ結果が表示されなくても問題ない。
Migration IDとMigration Nameはマイグレーションファイル名である。
一番左の「Status」に注目すると、、
「up」はマイグレート済み、「down」はまだマイグレートされていないことを表している。
つまりStatusが「up」になっているマイグレーションファイルはいじってはいけない、ということになる。
誤ってつくったテーブルを修正するには
続いて、マイグレーションファイルを誤って編集し、そのままマイグレートもしてしまった場合の修正方法を確認する。
これまでみた通り、一旦マイグレートしたファイルは編集してはいけないのであった。
その時に使用するのが下記のコマンドとなる。
以下のコマンドは、今は「実行しません」
$ rails db:rollback
これはロールバックという操作で、一度実行したマイグレートをキャンセルするためのものである。
実行すると、最後に実行されたファイル1つ分が実行前の状態に戻る。
ロールバックを行なってテーブルの修正をするときは下記の順番で操作を行う。
要点チェック
