まとめ
- Xethron/migrations-generator: Laravel Migrations Generator: Automatically generate your migrations from an existing database schema.
- テーブルを作成する migration ファイルを 1 テーブルにつき 1 ファイルで出力することができる。
- なお、レコード情報を出力することはできない。よって、データベースのダンプファイルがあるならば、この作業は不要で価値のないものかもしれない。
- Xethron/migrations-generator で生成された内容で注意する点 – oki2a24
バーション情報
- Laravel Framework 5.5.45
- Laravel Migrations Generator v2.0.2
マイグレーションファイル生成の対象としたデータベース情報
- インストールし、テーマやプラグインは追加・削除せずにアップデートを行なった WordPress 5.2.1 のデータベース
Laravel Migrations Generator をインストール
実際の様子です。 Composer は Docker コンテナを使い捨てで使用しているので、上述のコマンドとは完全には一致していません。また、 Carbon のバージョンが古いと警告が出ていますが、これは Laravel 5.5 をインストールするときにも出ていました。ですので、今回の Laravel Migrations Generator のインストールが原因ではないと思います。
Laravel Migrations Generator の help
マイグレーションファイルの生成実践
- 実践する前に
php artisan migrate
は 1 度も行なっていない。 - "Do you want to log these migrations in the migrations table? [Y/n] :" を y とすると、 生成するマイグレーションファイルをマイグレート実行したことにした情報を migrations テーブルに記録できる。
マイグレーションファイルの生成結果
ファイル
実践時の出力の通りのファイルが生成されました。その中の 1 ファイルの内容です。テーブル名は wp_commentmeta です。
database/migrations/2019_06_02_043145_create_wp_commentmeta_table.php
- 外部キーは、もともとないのでマイグレーションファイルにもない。
このテーブルの CREATE 文は次です。うまくマイグレーションファイルが生成されていることがわかります。
データベース
migrations テーブルに、今回生成したファイルを使ってマイグレーション実行したことにするログを残したので、テーブルの中身は次のようになっていました。なお、このコマンド実行以前にマイグレーションを実行したことはなかったため、 migrations テーブルは存在していませんでした。なので、マイグレーションファイル生成によって、 migrations テーブルの作成と、マイグレーションの実行が行われた (実際には行われていないが DB テーブル上は行われたことになった) ことになります。
ちなみに、 "Next Batch Number is: 1. We recommend using Batch Number 0 so that it becomes the "first" migration [Default: 0] :" で 0 ではなく n (n は "Next Batch Number is: 1." の数字。今回は 1) を指定すると、 php artisan migrate:rollback
したときに実際にロールバックされてテーブルは削除されてしまいます。
php artisan migrate
で元に戻りますけれども、レコードは当然ながら戻りません。
余談。 WordPress の datetime 型のデフォルト値 ‘0000-00-00 00:00:00’ は問題を引き起こす
それに、今回 WordPress 5.2.1 の DB 情報を使いました。これには問題があって、 p artisan migrate` で元に戻るどころか、エラーとなって落ちました><。
問題の内容は、調べますと、 MySQLの0000-00-00 00:00:00は使ってはならない – そーだいなるらくがき帳 のページが詳しかったです。
もう少し、調べますと、 WordPress はもともとデフォルト値に 0000-00-00 00:00:00 を使っており、 WordPress 的には正しく、 DB ダンプファイルやマイグレーションファイルが悪いわけではありませんでした。
となると、 WordPress のデータベースのみを使い、 Laravel でアプリを開発する場合は、この問題を解決する必要がありそうです。
おわりに
実際に、システムのリプレースという仕事を想定した場合、データベース構造とレコードはそのまま使い、プログラムをゼロから作り直す、という業務は結構あると思います。
Laravel で作ろう、となった場合、テーブルはすでにあるわけですから、それらに対応するマイグレーションファイルを作る、ということは別にやらなくても良いのではないかと、ここまでやってきて何ですが感じました。
データベース構造はそのまま使い、データはいらない、というケースであれば有用と思いますが、そのようなケースは思いつきません。。。
以上です。