マイグレーションファイルの修正、削除について

## 概要
・マイグレーションの扱いについて
・修正、削除する方法は２つある
・rails db:rollbackで修正、削除する方法
・コマンドラインを使用しての修正、

## マイグレーションの扱い
・テーブルの設計図や仕様のこと
・データーベースにテーブルを作成するために必要なファイル
・カラム名に対して、カラムの型を指定する
　integer型（数値）、string型（短文の文字）、text型（長文の文字）などがある

 モデルを作成
 ```
 rails g model テーブル名(複数形)
```
 ↓
 モデル作成時に生成されるマイグレーションファイルに必要な情報を記述する
 
```
class CreateAddresses < ActiveRecord::Migration[6.0]
  def change
    create_table :addresses do |t|
    # t.カラムの型 :カラム名, 　　　　オプション
      t.string :postal_code,    null: false
      t.string :city,           null: false
      t.string :street_unmber,   null: false
      t.string :phone_number,   null: false
      t.references :order,      null: false, foreing_key: true
      t.timestamps
    end
  end
end
```
記述したテーブルのカラムを反映するためにターミナルでマイグレーションを実行
```
rails db:migrate
```
ターミナルのログに以下のような記述があれば成功！
```
== 20XXXXXXXXXXXX CreateAddresses: migrating ======================================
-- create_table(:addresses)
   -> 0.0395s
== 20XXXXXXXXXXXX CreatePosts: migrated (0.0396s) =============================
```
データベースにテーブルがあるかを確認。


## 修正、削除の2つ方法
一度マイグレーションを実行した後で修正したい時がありますよね。
しかし原則、マイグレーションファイルを修正する場合、先ほど作成したファイルを直接編集することは出来ません。
マイグレーションファイルはデータベースのスキーマ変更を追跡するためのものであり、一度適用（マイグレート）されたマイグレーションは原則として変更しないでください。
どんなに小さな修正でも、新たなマイグレーションファイルを作成し、そこで変更を行います。これにより、データベースのスキーマ変更の履歴を正確に保つことができます。

**編集する場合は**
`rails db:rollback`を行い、statusをup→down状態にし、マイグレーションファイルを直接修正する
のと
修正するようのマイグレーションファイルを新たに別に作成し、テーブルのカラム名を変更させる。
それぞれ解説していきます。

## rails dn:rollbackを用いる方法
`rails db:migrate:status`でマイグレーションの状況を確認
```
rails db:migrate:status
```
実行するとマイグレーションの履歴が表示され、マイグレーションが適応されているとstatusがupになっている
```
# rails db:migrate:stauts 実行結果

database: アプリ名_development

 Status   Migration ID    Migration Name
--------------------------------------------------
   up     20201001015223  Create orders
   up     20201001092756  Create addresses
   up     20201014023427  Add id to addresses
   up     20201014030100  Add id to orders
```
upの状態でマイグレーションファイルを修正することは出来ません。やってはいけません。
`rails db:rollback`を実行しdownにする。down状態であると修正することができる。
```
database: アプリ名_development

 Status   Migration ID    Migration Name
--------------------------------------------------
   up     20201001015223  Create orders
   up     20201001092756  Create addresses
   up     20201014023427  Add id to addresses
  down    20201014030100  Add id to orders
```
マイグレーションファイルを直接修正を加えた後に`rails db:migrate`を実行すると修正内容がテーブルに適応される。

`rails db:rollback STEP=数値(戻りたい箇所が下から数えて何番目か)`でdownにするファイルの選択を広げることができる。
```
% rails db:rollback STEP=2
```
こうすると
```
database: アプリ名_development

 Status   Migration ID    Migration Name
--------------------------------------------------
   up     20201001015223  Create orders
   up     20201001092756  Create addresses
  down    20201014023427  Add id to addresses
  down    20201014030100  Add id to orders
```
になり、適切なマイグレーションファイルを選択することが出来る。

## 変更用のマイグレーションファイルを作成し、修正する場合
**テーブル名を修正したい場合**
```
rails g migration ChangeColumnNameUsersTable` Usersは対象のテーブル名
```
これにより、新たにマイグレーションファイルが生成される。
生成されたマイグレーションファイルをchangメソッドで編集する。
```
def change
    rename_column :users, :email, :email_address
  end

rename_columnメソッドは以下の引数を受け取ります。
* 		変更を行うテーブルの名称
* 		変更前のカラム名
* 		変更後の新しいカラム名

以上の変更を行った後、マイグレーションを実行します：
```
**カラムの追加、削除したい場合**
生成されたマイグレーションファイルをchangメソッドで編集する。
```
# カラムの追加
class AddNamesToUsers < ActiveRecord::Migration[6.0]
  def change 
  # カラムの追加
    add_column :users, :first_name, :string
    # カラムの削除
    remove_column :users, :last_name, :string
  end
end
```
**references型カラムの追加/削除 実行手順**
itemテーブルに外部キーとしてuser_idを追加する。
```
class AddUserIdToItems < ActiveRecord::Migration[7.0]
  def change
    add_reference :items, :user, null: false, foreign_key: true
  end
end
```
テーブルに反映する場合に
```
rails db:migrata
```
実行する。

## rollbackする方法とマイグレーションファイルを作成して修正する方法の使い分け
**マイグレーションファイルのロールバック**
マイグレーションのロールバックは主に、直近のマイグレーションで何らかのエラーや問題が生じたときや、マイグレーションの変更を元に戻したいときに使用します。もし直近のマイグレーションがまだ共有されていない（つまり、他の開発者や本番環境にはまだ反映されていない）場合、ロールバックしてマイグレーションを修正し、再度マイグレーションを行うことが可能です。

**新しいマイグレーションファイルを作成する方法**
新しいマイグレーションファイルを作成する方法:
一方、マイグレーションがすでに共有されている（つまり他の開発者や本番環境に反映されている）場合、ロールバックを行ってしまうと他の環境との整合性が保たれなくなってしまいます。このような場合には新しいマイグレーションを作成し、その中で変更を行うべきです。

具体的にどの方法を選ぶかは現状の状況やプロジェクト環境によって決めていくべきです。状況をしっかり把握してから行動するようにしていきましょう！