クエリの累計時間にタイムアウトを設定する（２）
前回の記事にてタイムアウトとなった場合に２種類の例外がスローされる事を説明しました。クエリ実行中にタイムオーバーとなった場合は、QueryException。クエリ実行外でタイムオーバーとなり、その後クエリを実行してエラーとなる場合は、自作したTimeoutExceptionです。今回はこれらのエラーをどうキャッチしてハンドリングするのか解説します。
クエリの累計時間にタイムアウトを設定する（１）
先日、管理サイトにてアラートが発生しました。調査すると、ある検索画面で利用者が重いクエリを連続で発行した事が原因でした。待ち時間が長かった為、不安になり検索ボタンを連打してしまったようです。サーバに負荷を掛ける操作については注意喚起するとして、待ち時間に制限が無いのはよくありません。そこで、検索処理に制限時間を設ける事にしました。今回はそちらの実装にあたって色々学んだことがあるので紹介します。
【Eloquent】has() vs joinSub()
過去の記事でも紹介されていますが、親子（or 1対多）関係にあるModelにおいて、「１つ以上子を持つ親」などの条件で絞り込む際にhas()は便利です。 しかし、has()を使わずともjoinSub()でサブクエリを指定して同じ条件で絞り込む事もできそうです。 どちらを使うのがベターなのか？気になったので調べてみました。
DBテーブルをjoinして値を更新
これまた、データベースの話ですが、長期でアクティブに管理しているプロジェクトでは必ず登場してくる作業です。
from句のサブクエリ
集計用のコマンドを書いていてクエリビルダでfrom句にサブクエリを使いたいケースが発生しました。公式ドキュメントを見てもwhere句かjoin句でのサブクエリしか書かれていません。恐らくこうやるのでは？と、試してみたら期待通りに動いてしまい、結局、不安になってソースを確認したのでその共有です。
DB変更履歴の作成（４）パッケージ
DB変更の履歴の作成をトレイトで簡単にEloquentのモデルに装着できるとしたころまでが前回ですが、巷では似たような仕組みでより良いパッケージがすでにあります。今回はそれを紹介します。
DB変更履歴の作成（３）トレイト
前回のDB変更履歴保存のメカニズムは、Userのモデルのためだけですが、どのモデルでも同様なことが簡単にできるようにトレイトを作成してみます。
DB変更履歴の作成（２）監査のデータを保存
前回においては、Eloquentのbootメソッドを利用してDB変更の情報（監査の情報）を取得することができました。今回は、これをDBに記録する部分を考えてみましょう。
DBの変更履歴の作成
データベースに保存されているデータはいつも現時点での値であり、過去の値は保存されていません。しかし、レコードのデータがどう変更したかという情報は重要です。どう変更したかだけではなく、誰がいつ、アプリのどの機能を使用して、さらにはどういう理由で、という情報も必要になってきます。例えば、カスタマサポートにおいて、会員の住所が変更されて注文した商品が届かなかったとき、それらの情報があれば、いついつにお客様が住所を変更しましたね、とか即答できます。さて、これらの変更イベント時の変更情報（監査あるいはAudit情報）、Laravelではどのように効率的にDBに保存することが可能でしょうか？
DBの負荷の緩和（3）コントローラにより接続を変える
マスターDBの変更が複製DBに反映されるまでの時間差を考えると、サイトの特定のページでは複製DBのアクセスを使用したくないかもしれません。例えば、会員のログインなど会員のアカウントの情報に関わるページとか、Eコマースのチェックアウトのページとか、あるいは管理者のみがアクセスする管理ページとか。そうなると、特定のコントローラだけに複製DBコネクションを限定するにはどのようにすればよいのでしょう？