概要
- モデルクラスで$fillableの配列を定義する意義を簡単にまとめる。
意義
-
$fillableの配列では許可するカラム名を指定する。 -
何を許可するのかというと、一括代入（モデルクラスのcreateメソッドやupdateメソッドの引数として一括で配列を受け取って処理する）を許可している。
-
$fillableの配列で指定されたカラムの一括代入を許可するのだ。 -
$fillableを定義しない場合何が起きるのかを見てみよう。 -
usersテーブルに下記のカラムがあるとする。
- name
- password
- phone
-
「電話番号は初回登録後変更できないサービス」だったとする。
-
create時には下記のようにモデルを呼び出してレコードを作成する。
use App\Models\User; // 説明のため、擬似的にリクエストの配列を定義する $request = [ 'name' => 'Foo Bar', 'email' => 'test@example.com', 'password' => 'password01234', 'phone' => '0123456789', ]; User::create($request); -
上記の処理は
$fillableを定義していようが、いまいが、あまり関係ない。 -
更新の場合はどうなるだろうか。「電話番号は初回登録後変更できないサービス」を念頭に置く。
use App\Models\User; // 説明のため、擬似的にリクエストの配列を定義する $request = [ 'name' => 'Hoge Fuga', 'email' => 'test_01@example.com', 'password' => 'password56789', ]; User::update($request); -
updateメソッドに渡される配列のキーが
name,email,passwordのみの場合「電話番号は初回登録後変更できないサービス」のルールが守られる。 -
しかしながら
$fillableを定義していないばっかりに、下記のような値がupdateメソッドに渡った場合phoneが更新され、「電話番号は初回登録後変更できないサービス」のルールが守られない。use App\Models\User; // 説明のため、擬似的にリクエストの配列を定義する $request = [ 'name' => 'Hoge Fuga', 'email' => 'test_01@example.com', 'password' => 'password56789', 'phone' => '1112131415', ]; User::update($request); -
ただし、これは「
$fiilableを定義していない」「バリデーションルール未設置」「リクエストのキー、バリューをそのままcreateやupdateメソッドに渡してしまう」などの悪条件が重なったときにだけ発生する。しかし、コードを記載する時にミスは付き物であるため必ず$fillableは設定したほうが良いと思う。 -
今回の場合Userモデルクラスでは下記のような
$filalbleを定義することになるはず、、！User.PHP$fillable = [ 'name', 'email', 'password', ]; -
createメソッドの戻り値は作成したレコードの情報をもったモデルインスタンスなのでちょっと回りくどくなるが下記のようにcreateの時は記載できる（いや、こんな上長な書き方以外にもっと良い書き方があるかも。少なくともトランザクションは貼ったほうが良いかも）
use App\Models\User; // 説明のため、擬似的にリクエストの配列を定義する $request = [ 'name' => 'Foo Bar', 'email' => 'test@example.com', 'password' => 'password01234', ]; $user = User::create($request); $user->phone = '0123456789', $user->save(); -
これならcreateやupdateメソッドでphoneの値がはいらないようにブロックすることができる。