0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 1 year has passed since last update.

【Rails】マイグレーション履歴を正しくしてみた

Posted at

はじめに

前任者が構築したRails周りを確認していたら、マイグレーション履歴がおかしいことを発見しました。

①マイグレーションファイルは存在しており、マイグレーションファイル内容もDBに反映されているが、マイグレーションファイルのステータスがdownになっている。
②マイグレーションテーブル(schema_migrations)に実行履歴がない。

何故この様な状態になったのか、どの様に運用していたのか、経緯は前任者がいなくなったので確認できませんでした。
とりあえず正しい状態にするためにやったことを備忘として残しておきます。

現状確認

1.マイグレーション履歴を確認
「Status」は全てdownになっていた。
以下はサンプルであり、実際の「Migration ID」や「Migration Name」から変えています。

$ rails db:migrate:status

database: DB名

 Status   Migration ID    Migration Name
--------------------------------------------------
 down     20200101010101  Create XXX
 down     20200202020202  Add column XXX
 down     20200303030303  Add column XXX
 down     20200404040404  Modify column XXX
  ・
  ・
  ・

2.マイグレーションファイルを確認
マイグレーションファイルは存在した。

$ cd db/migrate/
$ ls -l
-rw-r--r-- 1 root root  820 Apr 1 11:11 20200101010101_create_xxx.rb
-rw-r--r-- 1 root root  751 Apr 1 11:11 20200202020202_add_column_xxx.rb
-rw-r--r-- 1 root root  775 Apr 1 11:11 20200303030303_add_column_xxx.rb
-rw-r--r-- 1 root root  836 Apr 1 11:11 20200404040404_modify_column_xxx.rb
  ・
  ・
  ・

3.マイグレーション実行管理テーブルを確認
schema_migrationsテーブルにレコードがなかった。

mysql> SELECT * FROM schema_migrations;
Empty set (0.00 sec)

対応内容

マイグレーション履歴をupにするにはいくつか方法がありますが、schema_migrationsテーブルにレコードを追加してしまうのが一番手っ取り早いという結論に至りました。
この方法でよいかどうかは、システム運用次第であるので、ベストプラクティスではありません。

mysql> INSERT INTO schema_migrations (version) VALUES 
     ('20200101010101'),
     ('20200202020202'),
     ('20200303030303'),
     ('20200404040404'),
             ・
             ・
             ・
;

対応後確認

1.マイグレーション履歴を確認
「Status」は全てupに変わった。

$ rails db:migrate:status

database: DB名

 Status   Migration ID    Migration Name
--------------------------------------------------
   up     20200101010101  Create XXX
   up     20200202020202  Add column XXX
   up     20200303030303  Add column XXX
   up     20200404040404  Modify column XXX
  ・
  ・
  ・

2.マイグレーションファイルを確認
マイグレーションファイルに影響はない。(対応前後で変化なし)

$ cd db/migrate/
$ cd ls -l
-rw-r--r-- 1 root root  820 Apr 1 11:11 20200101010101_create_xxx.rb
-rw-r--r-- 1 root root  751 Apr 1 11:11 20200202020202_add_column_xxx.rb
-rw-r--r-- 1 root root  775 Apr 1 11:11 20200303030303_add_column_xxx.rb
-rw-r--r-- 1 root root  836 Apr 1 11:11 20200404040404_modify_column_xxx.rb
  ・
  ・
  ・

3.マイグレーション実行管理テーブルを確認
schema_migrationsテーブルに実行履歴レコードが存在する。

mysql> SELECT * FROM schema_migrations;
+----------------+
| version        |
+----------------+
| 20200101010101 |
| 20200202020202 |
| 20200303030303 |
| 20200404040404 |
  ・
  ・
  ・
+----------------+
XXX rows in set (0.00 sec)

おわりに

前任者から引き継ぎを受けると、何でこんな状態になっているの?ということが往々にしてあると思いますが、自分が引き継ぐときは出来るだけ後任者に迷惑が掛からないように引き継ぎたいものである。
「立つ鳥跡を濁さず」である。

以上

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?