新規登録や更新でMassAssignmentException
Laradockで簡単アプリ作成しようとしたら、速攻でDB周り/日本語問題で躓いたけど、チャチャッと解決 - Qiitaに続けて、サンプル通りに実装してから動作確認で、新規作成や更新をしてみたら...
MassAssignmentException
のエラー
- Laravel4のEloquent ORMではまった件 - 終電23時15分って早くね?
- LaravelのfirstOrNewメソッドでMassAssignmentExceptionエラーが発生した時の対応 - Qiita
- 初めてのLaravel 5.1 : (11) Eloquent マスアサインメント – ララ帳
結果的には、モデルで指定するprotected $guarded
とprotected $fillable
の内、$guarded
を指定していたけれど、スペルをミスっていたというオチ
Orz
カラム追加などのマイグレーションのお作法
とりあえず、CRUDの一通りができるアプリができたので、カラム追加などの拡張をする前に、そのあたりのお作法について、お勉強
カラム変更の前に、ライブラリの追加が必要
composer require doctrine/dbal
- データベース:マイグレーション # カラム変更 5.4 Laravel
- laravelでのマイグレーション作成手順 - Qiita
- Laravelのマイグレーション - Qiita
- LaravelのMigrationについて調べた結果 - Qiita
- 初めてのLaravel 5.1 : (8) マイグレーションの作成 – ララ帳
- artisan migrate で dropColumnがエラーになりハマる – ララ帳
あと、マイグレーションファイル内に記載されているclass名に関する留意点。
テーブル定義を変更する場合は、class名が被らないようにした方がよいらしい。
コマンド言うと、マイグレーションファイルを作成する際に指定する {migration_class_name} の部分。
php artisan make:migratoin {migration_class_name} --table=users
これが、プロジェクト全体で被らないようにした方がよい、とのこと。
都度、php artisan migrate しているときには発生しなくて、新規環境で、一括でmigrateを実行したときに発生するっぽいので、しばらくして、新規でDB作り直すかぁ、とかならないと気づかないってことかしら...
だとすると、開発中は、カラムの抜き差し等が頻繁に発生しそうなので、初回リリースのタイミング、もしくは、ある程度、テーブル構造が固まったタイミングで、一度、まっさらな新規作成のマイグレーションファイルを作成するようにして、それ以降、変更管理をすると良いかもしれないなぁ。
つまり、初回リリース時/ある程度、テーブル構造が固まった時に、開発中に行った追加変更のマイグレーションをすべてマージして、一つのマイグレーションファイルに集約するようなイメージ
単一入力値による複数カラムに対する曖昧検索の実装
で、この作業のゴールは、複数カラムに対する全文検索をどう実装すれば良いかを知ることだったので、ざっくりの実装方法を理解できたところで、全文検索についてクリッピング
アナログな実装
- Lravel5で複数Keyword検索+paginate (Eloquent編) - Qiita
- Laravel where条件の使い方 | Webエンジニアブログ
- 【Laravel】複数条件の検索フォームを作る方法【whereRaw】
- 【Laravel】ページネーション付き検索フォームを作成する方法
- mysql - Laravel multiple column eloquent search query - Stack Overflow
標準的な機能を利用して、実装するなら、検索対象のカラムの数だけ、or検索を指定すれば良さそう。
Model::where('target_column1', 'LIKE', "%$query_keyword%")->orWhere('target_column2', 'LIKE', "%$query_keyword%")
MySQLの生成列とFULLTEXTで実装
もっと今時な?実装をするなら、MySQLの5.7.6から利用できるようになったgenerated columns、日本語訳だと、生成列とか仮想列とか呼ばれているカラム定義で、これにFULLTEXTインデックスを定義すれば、行けそう
- まだ日本語全文検索で消耗してるの? - Qiita
- JSON型にindexも!MySQL 5.7のGenerated Columnsの可能性について探る - UUUM攻殻機動隊
- InnoDBにおける仮想列および効果的な"関数インデックス"(MySQL Server Blogより) | Yakst
- 日々の覚書: MySQL 5.7.8からInnoDBのgenerated columnは実体を取らずにインデックスを作れるようになった
- MySQL 5.7で生成カラムを使って関数INDEXを作成する - Qiita
- Migration column modifiers
- laravel - How to add a virtual column with the schema builder? - Stack Overflow
- FULLTEXT Indexes at migrations
- MySQL :: MySQL 5.7 Reference Manual :: 12.9.8 ngram Full-Text Parser
留意点としては、generated columnを指定する際、生成列のデータの持ち方が初期値はVIRTUALなので計算後の値が格納されず、FULLTEXTのインデックスを設定できないため、STOREDを設定する必要がある
具体的には、マイグレーションファイルに、以下のような記述をするのかな。
(参考ページのサンプルを丸っと転機して少し修正w)
# カラム定義
Schema::create('sales', function (Blueprint $table) {
$table->string('name');
$table->double('price_eur');
$table->integer('amount');
$table->double('total_eur')->storedAs('price_eur * amount');
$table->double('total_usd')->storedAs('total_eur * xrate');
$table->double('xrate');
});
# ALTER TABLE か CREATE INDEX で追加設定
DB::statement('ALTER TABLE `sales` ADD FULLTEXT INDEX `ft_idx_total_eur` (`total_eur`) WITH PARSER ngram');
DB::statement('CREATE FULLTEXT INDEX `ft_idx_total_eur` ON `sales` (`total_eur`) WITH PARSER ngram');
generated columnsは、サブクエリに対応していないことによる影響の有無を、事前に検討しておいた方が良さそう
ちょっとクリティカルな問題として、性能に難あり、らしい
性能に課題はありそうだが、数百〜数千レコーデあれば、FULLTEXTを利用して、Laravelから全文検索する方法
いずれも、MATCH ... AGAINST ...
で検索する方法
Laravelが提供している全文検索の機能で実装
LaravelのScoutのことがよくわからなかったんだけど、これ読んで、たぶん、理解できた。
- Laravel Scout で AWSのElasticSearch を使う - Qiita
- Elastic Driver for Laravel Scout - ErickTamayo/laravel-scout-elastic - GitHub
- Scout Elasticsearch Driver - babenkoivan/scout-elasticsearch-driver - GitHub
- babenkoivan/scout-elasticsearch-driver - Packagist
全文検索のためのインデックスは外部で処理して、フレームワークからは気軽にメソッドで検索できるようにしたものってことかな
対象カラムは、各モデルごとにtoSearchableArray
メソッドで定義できるってことかな...。
ただ、これも複数のテーブルにまたがるような検索や、カラムの値はIDでしか持っていないような項目を対象にした場合は、工夫が必要そう...。
おまけ
ちょっと話が逸れるけど、結合先のテーブルを検索条件に加えるという話も出てきそうなので、メモ