前回の記事にてタイムアウトとなった場合に２種類の例外がスローされる事を説明しました。クエリ実行中にタイムオーバーとなった場合は、QueryException。クエリ実行外でタイムオーバーとなり、その後クエリを実行してエラーとなる場合は、自作したTimeoutExceptionです。今回はこれらのエラーをどうキャッチしてハンドリングするのか解説します。
先日、管理サイトにてアラートが発生しました。調査すると、ある検索画面で利用者が重いクエリを連続で発行した事が原因でした。待ち時間が長かった為、不安になり検索ボタンを連打してしまったようです。サーバに負荷を掛ける操作については注意喚起するとして、待ち時間に制限が無いのはよくありません。そこで、検索処理に制限時間を設ける事にしました。今回はそちらの実装にあたって色々学んだことがあるので紹介します。
factoryを使ったダミーデータ作成方法の3回目です。今回は、複数のデータ作成に便利なsequenceメソッドと、そのユースケースをご紹介します。
個人で色々試したいものがある時に最新のPHPが必要となる事が多々あります。そんな時、今まではHomebrewで両方のversionをインストールして環境変数のパスを手作業で切り替えていましたが、正直面倒です。今回はPHPBrewを使ってそんな面倒が解消されるか試してみます。今回の記事は私の作業環境であるmacOSでの話となります、ご承知ください。
factoryを使ったダミーデータ作成方法の２回目です。前回は単一モデルを扱った内容でしたが、今回は「１対多」のリレーションデータを作成します。
プログラムの中のどこからでもカスタムログを作成できるようにしたのは前回の話。今回はそのログを例えば３ヶ月ごとにローテーションしてみます。
プログラムの中で必要なときにちょろっとある情報をログに残したい、しかもlaravel.logではなくカスタム（ここが大事）のログファイルを作成して残したい、というのが私の願いです。さて、どうプログラムするか？
普段、エラーバッグからエラーを取得する際、$errors->first(’name’)などとしますが、この時裏ではどんな処理が行われているかご存知でしょうか？私自身、全然意識せずに使っていましたが、調べてみると実はdefaultという名前付きエラーバッグからエラーを取得している事が分かりました。
１つのページに複数のフォームが存在する場合、エラーの管理が煩雑になりがちです。 そんな時は名前付きエラーバッグを使ってフォーム毎にエラーを分けると管理しやすいです。
テスト用のダミーデータを作成する際、factoryをよく使います。factoryを使ったダミーデータの作成方法は色々ありますが、今回は単一Modelのデータ作成でよく使う記述をご紹介します。