スイーツ（笑）と呼ばないで!!

たまに社内SNSでSeederについて話題にあがる。

Seederは、一般的には、テーブル定義が変わった時なんかに、
一度テーブルの中身をリフレッシュして再度テストデータを埋め込む、
こんな利用シーンが多いだろうか。

今日見かけたのは

　php artisan db:seed --class=DevelopmentSeeder

という1行。

—classとオプションを指定することで特定のSeederクラスを実行できる。

命名から開発環境のテストデータを作り直したいのだなと思う。

中を見てみると、複数のテーブルにinsertする記述がこの1つのファイルに書かれている。

みんないろんな使い方をしているようだ。
もちろん、使い方に正解があるわけではない。

今日は、自分だったらどうするかなー、というのを考えてみたいと思う。

前述の例の--classのオプションを指定しないでdb:seedを実行するとどうなるか。

デフォルトではLaravelが最初に用意しているDatabaseSeederというSeederが実行される仕様となっている。

Seederは別のSeederを呼び出すことができる。

runメソッドの中で

　$this->call(’Seederのクラス名’);

という感じだ。

おそらくLaravelのSeederの設計思想としては、
DatabaseSeederのrunメソッドの中に複数のSeederをcallするような想定でいるのではないかと思える。

Laravelの公式ドキュメントのサンプルでも

public function run()
{
　Model::unguard();

　$this->call(UserTableSeeder::class);
　$this->call(PostsTableSeeder::class);
　$this->call(CommentsTableSeeder::class);
}
なんて記述がある。

ここからもう一つわかることは、Seederはやっぱり基本はテーブル単位で作る想定よね、ということ。

さて、ここで少し話がズレるが、テーブル定義をリフレッシュする際に同時にSeederを実行したい時どのようなコマンドを打っているだろうか。

Laravelでは、実はmigrationと同時にSeederを実行する機能がある。

　php artisan migrate:refresh --seed

このように--seedオプションをつければ一発で実行できる。
この際呼ばれるSeederはデフォルトのDatabaseSeederだ。

こんなことからも、Laravelとしては、DatabaseSeederを親としてrunの中で子Seederを呼んで欲しいんじゃないかな、と思ったりする。

え、developmentとかproductionとか環境ごとにSeederが変わる場合はどうしたら良いかって?

私が考える正解は、

DatabaseSeederの中で環境毎のSeeder(例えば、LocalSeeder、ProductionSeeder等の「環境名」+Seeder)をcallし、その環境毎のSeederの中で、その環境必要に応じて各テーブルのSeederをcallしてあげればよい、

というもの。(本番では呼びたくないとかあるもんね)

もちろん、if文で分けるなんてかっこ悪いことはせずに、環境の名称からクラスを特定するか、
より柔軟にするならLaravelのconfigは環境ごとに設定を記述できる仕組みになっているので、そこでその環境の親Seederのクラス名を書けば設定が上書きできるようにすると良いと思う。

ちなみに、artisanコマンドで環境を指定するには--envオプションを使えば良いね。

例えば
　php artisan migrate --env=local
こんな感じで環境を指定できる。

ということで、いろいろ書いてきたけど、これはあくまで私ならこうするかも、というもの。

皆、それぞれ使いたいように使えば良いさー (沖縄風)

[0回]

• プログラミング
• COMMENT：0