L9.x on ララジャパン

artisan dbコマンド

Mon, 08 Jan 2024 02:33:53 +0900

Laravelの最新バージョンは10xでもうすぐに11xがリリースされます。しかし、Laravel 9xでartisan dbコマンドにオプションが増えていることについ最近気づいたので、忘れずにここで紹介します。

Laravel 9x以前から存在したdbコマンド

db:seed

まず、データベースにシードのレコードを作成するコマンドです。

$ php artisan db:seed

と実行すると、以下のDatabaseSeederがデフォルトで使用されます。

database/seeders/DatabaseSeeder.php

namespace Database\Seeders;

// use Illuminate\Database\Console\Seeds\WithoutModelEvents;
use Illuminate\Database\Seeder;

class DatabaseSeeder extends Seeder
{
    /**
     * Seed the application's database.
     */
    public function run(): void
    {
        \App\Models\User::factory(10)->create();　// 10個のusersのレコードが作成されます

        // \App\Models\User::factory()->create([
        //     'name' => 'Test User',
        //     'email' => 'test@example.com',
        // ]);
    }
}

新規のプロジェクトでは、seedを実行する前には以下のようにmigrateを実行しましょう。

しかし、プロダクションではこんなに簡単に実行できると危ないと思いませんか？ちなみに、上の実行の環境では、.envでAPP_ENVはlocalで私の開発環境設定です。

.env

APP_NAME=Laravel
APP_ENV=local
...

この値が、productionのときには、上のコマンドを実行すると、

と警告してくれて実行してOKかどうか質問されます。しかし、それでも実行は可能です。注意しましょう。

db:wipe

db:seedは実行する環境によっては危険なコマンドでしたが、こちらはもっと危険です。以下は、APP_ENV=localでの実行ですが、有無も言わさずにDBのテーブルをすべて削除してしまいます。

もちろん、APP_ENV=productionのときには、db:seedと同様に警告と確認のステップがあります。

Laravel 9xで登場したdbコマンド

今度は、Laravel 9xで追加されたコマンドたちです。先のDB操作のコマンドとは違って今度はどれもDBの情報をすぐにチェックできる有用なコマンドです。

db:monitor

現在のDBの接続数を表示するコマンドです。

db:show

DBの情報を表示するコマンドですが、Doctrine DBAL (doctrine/dbal)のパッケージがインストールされていないと、インストールするかどうかが問われます。YESとすると、必要なパッケージがインストールされます。

インストール完了後、再度実行すると、

db:table

こちらは、DBテーブルの情報を表示するコマンドです。まず、どのテーブルの情報が必要か尋ねられます。

usersを選択してENTERすると、

DBテーブルの項目などテーブルの情報を表示してくれます。これはとても便利ですね。

コマンドにプログレスバーを追加する

Wed, 29 Nov 2023 00:25:29 +0900

一度に大量のデータを更新する必要がある時などはArtisanコンソールコマンドでバッチを作成して実行します。その際に更新に時間が掛かって途中で何も出力が無いと処理が正常に進んでいるのか不安になってしまいます。そんな時はプログレスバーを表示すれば進捗が確認できて便利です。

演習コマンド

Laravelにデフォルトで用意されているusersテーブルを用いて演習用のコマンドを作成し、使い方を確認していきます。作成するのは登録されているemailからユーザー名部分を抜き出し、nameを上書きするコマンドです。コマンドの実行には更新対象となるusersのレコードが必要となるので先にダミーレコードを準備しましょう。DatabaseSeeder.phpのrun()を以下の様に編集してください。

database/seeders/DatabaseSeeder.php

namespace Database\Seeders;

use Illuminate\Database\Seeder;

class DatabaseSeeder extends Seeder
{
    /**
     * Seed the application's database.
     */
    public function run(): void
    {
        \App\Models\User::factory(1000)->create();
    }
}

そして以下を実行するとusersに1000件のダミーレコードが作成されます。

$ php artisan db:seed

続いて演習用のUserNameUpdateコマンドを作成します。

$ php artisan make:command UserNameUpdate

UserNameUpdateコマンドは以下の様にしました。まだプログレスバーを実装する前の状態です。

app/Console/Commands/UserNameUpdate.php

namespace App\Console\Commands;

use App\Models\User;
use Illuminate\Support\Str;
use Illuminate\Console\Command;

class UserNameUpdate extends Command
{
    /**
     * The name and signature of the console command.
     *
     * @var string
     */
    protected $signature = 'app:user-name-update';

    /**
     * The console command description.
     *
     * @var string
     */
    protected $description = 'nameをemailのユーザー名に更新する';

    /**
     * Execute the console command.
     */
    public function handle()
    {
        $this->info('ユーザ名の更新を開始します。');

        $users = User::all();

        $users->each(function ($user) use (&$updated) {
            $user->name = Str::before($user->email, '@');
            $user->save();
            $updated++;
        });

        $this->info('ユーザ名の更新が完了しました。（更新件数：' . $updated . '）');
    }
}

以下を実行するとemailの’@‘より前の部分をnameに上書きします。

$ php artisan app:user-name-update
ユーザ名の更新を開始します。
ユーザ名の更新が完了しました。（更新件数：1000）

コマンド実行後にtinkerで以下を実行してみて下さい。ランダムにピックアップした２０件ですが、意図通りに更新されているのが確認できると思います。

> User::take(20)->inRandomOrder()->pluck('email', 'name');
= Illuminate\Support\Collection {#7081
    all: [
      "marjorie.hagenes" => "marjorie.hagenes@example.com",
      "owen.sipes" => "owen.sipes@example.org",
      "leann10" => "leann10@example.net",
      "amy21" => "amy21@example.net",
      "brooks.leffler" => "brooks.leffler@example.org",
      "arianna89" => "arianna89@example.com",
      "ledner.teagan" => "ledner.teagan@example.net",
      "axel17" => "axel17@example.org",
      "ykoepp" => "ykoepp@example.com",
      "rita19" => "rita19@example.net",
      "genevieve98" => "genevieve98@example.com",
      "nathen.goldner" => "nathen.goldner@example.net",
      "xjones" => "xjones@example.org",
      "assunta57" => "assunta57@example.com",
      "swift.vena" => "swift.vena@example.net",
      "senger.maybell" => "senger.maybell@example.org",
      "jace.willms" => "jace.willms@example.com",
      "stephanie.berge" => "stephanie.berge@example.org",
      "acremin" => "acremin@example.org",
      "yaufderhar" => "yaufderhar@example.org",
    ],
  }

一度コマンドを実行してnameが更新されてしまったので、以下を実行してダミーデータを作り直しておきましょう。

$ php artisan migrate:fresh --seed

withProgressBar()

それでは先ほどのコマンドを修正してプログレスバーを表示するようにしてみましょう。プログレスバーを表示するにはwithProgressBar()を使用します。withProgressBar()は第一引数にループ処理可能な値（iterable）を、第二引数にループ実行する処理をクロージャで指定します。UserNameUpdateコマンドに実装した例が以下になります。

app/Console/Commands/UserNameUpdate.php

...
    public function handle()
    {
        $this->info('ユーザ名の更新を開始します。');

        $users = $this->withProgressBar(User::all(), function (User $user) {
            $user->name = Str::before($user->email, '@');
            $user->save();
            usleep(10000);
        });

        $this->info('');    // 改行用
        $this->info('ユーザ名の更新が完了しました。（更新件数：' . $users->count() . '）');
    }
...

コマンドを実行するとバーが表示され、User::all()の総数である１０００件の処理が完了すると100%となるようにループ毎にゲージが溜まっていきます。

$ php artisan app:user-name-update
ユーザ名の更新を開始します。
1000/1000 [▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓] 100%
ユーザ名の更新が完了しました。（更新件数：1000）

今回ダミーデータを1000件用意しましたが、私の環境では処理が一瞬で終了してしまい、プログレスバーのゲージが蓄積していく様子が確認できなかったのでusleep()を挟みループ毎に0.01秒スリープするようにしました。また、プログレスバー表示後に改行コードが含まれておらず、続く「ユーザ名の更新が完了しました。・・・」の表示がプログレスバーと同じ行に表示されてしまう為、$this->info(’’)で改行を挟みました。

createProgressBar()

プログレスバーを表示するもう１つの方法としてcreateProgressBar()を使ってProgressBarインスタンスを生成する方法があります。こちらは前項のwithProgressBar()よりもバーを表示するタイミングやゲージを進めるタイミングを細かくコントロールできます。以下、UserNameUpdateコマンドに実装した例です。

app/Console/Commands/UserNameUpdate.php

...
    public function handle()
    {
        $this->info('ユーザ名の更新を開始します。');

        $users = User::all();

        $bar = $this->output->createProgressBar($users->count());
        $bar->start();

        foreach ($users as $user) {
            $user->name = Str::before($user->email, '@');
            $user->save();
            usleep(10000);
            $bar->advance();
        }

        $bar->finish();

        $this->info('');
        $this->info('ユーザ名の更新が完了しました。（更新件数：' . $users->count() . '）');
    }
...

今回のUserNameUpdateコマンドの様に取得したデータに対してループでシンプルな処理を実行するパターンでは前項で紹介したwithProgressBar()の方がコードが簡潔ですね。ループ内で実行する処理が複雑でクロージャに渡す変数が多くなってしまう様なケースではcreateProgressBar()を使用するのが良いかもしれません。因みにですが、withProgressBar()はLaravel8から追加された関数の様です。Laravel7以前はcreateProgressBar()のみでした。

isNotEmpty 空ではない

Sun, 13 Aug 2023 03:18:09 +0900

コレクションの空をチェックする関数は、isEmpty()、しかし現実では「～が空でないとき」という条件文も良く使います。もちろん、! で if (! $collection->isEmpty()) とすることでも十分なのですが、なぜか if ($collection->isNotEmpty()) の方が私にはわかりやすい。

４年前に、「正しいのはisEmptyでした」という記事を書いたのですが、不思議にもこの記事はとても人気がある記事となっています。過去のトップ１０に入っています。今回はこの反対の isNotEmpty() の紹介です。

まず、コレクションでは、

> $users = User::all();
= Illuminate\Database\Eloquent\Collection {#7175
    all: [
      App\Models\User {#7578
        id: 1,
        name: "name",
        email: "test@example.com",
        email_verified_at: null,
        #password: "$2y$10$wIaPHmNNWNtd.MoaR.SQFeiUCk5gAbHylHM4i6TkIh17rbv8US046",
        #remember_token: null,
        created_at: "2023-06-26 21:29:04",
        updated_at: "2023-06-26 21:29:04",
      },
    ],
  }

> if ($users->isNotEmpty()) echo 'ユーザーレコードが存在する';
ユーザーレコードが存在する

文字列のStrオブジェクトでは、

> $str = Str::of('空ではない')
= Illuminate\Support\Stringable {#7575
    value: "空ではない",
  }

> $str->isNotEmpty()
= true

ここで紹介した、HtmlStringのオブジェクトでも

> use Illuminate\Support\HtmlString;
> $html = new HtmlString('<h1>空ではない</h1>');
= Illuminate\Support\HtmlString {#7581
    html: "<h1>空ではない</h1>",
  }

> $html->isNotEmpty()
= true

最後に、エラーなど使用されるMessageBagでも、

> use Illuminate\Support\MessageBag;
> $errors = new MessageBag(['quantity', '数字でありません']);
= Illuminate\Support\MessageBag {#6215}

> $errors->all();
= [
    "quantity",
    "数字でありません",
  ]

> $errors->isNotEmpty()
= true

クエリの累計時間にタイムアウトを設定する（２）

Thu, 27 Jul 2023 11:10:26 +0900

前回の記事にてタイムアウトとなった場合に２種類の例外がスローされる事を説明しました。クエリ実行中にタイムオーバーとなった場合は、QueryException。クエリ実行外でタイムオーバーとなり、その後クエリを実行してエラーとなる場合は、自作したTimeoutExceptionです。今回はこれらのエラーをどうキャッチしてハンドリングするのか解説します。

検証用のページ

説明の為にテスト用のコントローラを用意しました。

app/Http/Controllers/TimeoutTestController.php

<?php

namespace App\Http\Controllers;

use App\Services\DbQueryTimeout;
use Illuminate\Support\Facades\DB;

class TimeoutTestController extends Controller
{
    public function index()
    {
        $timeout = (int) request('timeout');

        try {
            // 制限時間の指定があればセット
            if ($timeout) {
                DbQueryTimeout::set($timeout);
            }

            // 重いクエリ１
            DB::statement('select sleep(3) union select 1');

            // 重いクエリ２
            DB::statement('select sleep(5) union select 1');

        } catch (\Exception $e) {
            return 'error';
        }

        return 'success';
    }
}

ルーティングは以下の通りです。

routes/web.php

<?php

use Illuminate\Support\Facades\Route;
use App\Http\Controllers\TimeoutTestController;

Route::get('/timeout_test', [TimeoutTestController::class, 'index']);

indexアクションでは重いクエリが２つ実行されます。それらが正常に処理できた場合はsuccess、何かしらのエラーが発生した場合はerrorを返します。尚、GETパラメタでtimeoutの指定がある場合は、DbQueryTimeoutを使用して制限時間が設定されます。ビルドインサーバーを起動して挙動を確認してみましょう。

php artisan serv

まず、パラメタ無しで /timeout_test へアクセスしてみてください。約8秒後にsuccessと表示されるはずです。次に、timeoutパラメタを指定して制限時間を設定してみましょう。/timeout_test?timeout=5 として制限時間を5秒にしてアクセスしてみて下さい。すると、約５秒後に処理が中断されerrorと表示されるはずです。

Tips: 重いクエリをシミュレートする方法

重いクエリ = 時間が掛かるクエリ、という事でDB側でsleep()を実行してシミュレートできます。mysqlではsleep()は正常にスリープできた場合は0、途中で中断された場合は1が返却されます。しかし、実際の環境ではmax_execution_timeで指定した時間をオーバーして処理が中断された場合は１ではなくエラーが発生します。sleep()においてもタイムオーバーした場合にエラーを返させるには、unionで追加の処理を実行すればOKです。追加の処理はなんでも良いので今回は適当にselect 1としました。実際にmysql clientにて以下を実行して試してみると理解しやすいと思います。

# 制限時間を5秒に設定
mysql> set max_execution_time = 5000;
Query OK, 0 rows affected (0.01 sec)

# 制限時間内に終わるsleepなら0が返却される
mysql> select sleep(4);
+----------+
| sleep(4) |
+----------+
|        0 |
+----------+
1 row in set (4.05 sec)

# 制限時間内に終わらずsleepが中断されたら1が返却される
mysql> select sleep(5);
+----------+
| sleep(5) |
+----------+
|        1 |
+----------+
1 row in set (5.06 sec)

# unionで追加の処理を含めるとエラーが返却される
mysql> select sleep(6) union select 1;
ERROR 3024 (HY000): Query execution was interrupted, maximum statement execution time exceeded

エラーのハンドリング

冒頭で述べた通り制限時間をオーバーした場合は２種類のタイムアウトエラーが発生します。しかし、アプリにおいては当然それ以外のエラーも発生し得るので、タイムアウトエラーとそうでないエラーの場合で判別してエラーを出し分ける必要があります。それぞれどの様に判別すれば良いでしょうか。

TimeoutExceptionをキャッチ

先に簡単な方から、TimeoutExceptionを判別する場合です。こちらはシンプルにスローされたExceptionのインスタンスをチェックすれば判別できます。TimeoutTestController.php のindexアクションを以下の様に書き換えてみましょう。

app/Http/Controllers/TimeoutTestController.php

...
    public function index()
    {
        $timeout = (int) request('timeout');

        try {
            // 制限時間の指定があればセット
            if ($timeout) {
                DbQueryTimeout::set($timeout);
            }

            // 重いクエリ１
            DB::statement('select sleep(3) union select 1');

            // クエリ以外の処理で3秒掛かった
            sleep(3);

            // 重いクエリ２
            DB::statement('select sleep(5) union select 1');

        } catch (\Exception $e) {
            // TimeoutExceptionの場合のエラー文言
            if ($e instanceof TimeoutException) {
                return 'timeout error';
            }

            return 'error';
        }

        return 'success';
    }

TimeoutExceptionは、クエリ実行外でタイムオーバーし、次のクエリが実行されるタイミングでスローされます。そちらを再現する為に、クエリ１とクエリ２の間にPHP側のスリープを3秒挟みました。これにより制限時間が5秒の場合はTimeoutExceptionがスローされるはずです。再度、ビルドインサーバにて/timeout_test?timeout=5へアクセスしてみて下さい。今度はtimeout errorと表示されたはずです。

クエリ実行中にタイムアウトした場合のエラー

クエリ実行中にタイムアウトした場合はQueryExceptionがスローされます。QueryExceptionはタイムアウト以外でもスローされる例外ですので、前項のTimeoutExceptionの様にインスタンスだけではタイムアウトエラーを判別できません。判別には一歩踏み込んで、$e->errorInfoのチェックが必要です。errorInfoはQueryExceptionの親クラスであるPDOExceptionにセットされていた値で、PHPマニュアルによると、データベースハンドラにおける直近の操作に関連する拡張エラー情報が配列で格納されています。タイムアウトエラーとしてQueryExceptionがスローされた際の$e->errorInfoは以下の様になります。

[
  0 => "HY000"
  1 => 3024
  2 => "Query execution was interrupted, maximum statement execution time exceeded"
]

0はSQLSTATEエラーコード、1はドライバ固有のエラーコード、2はそのエラーメッセージです。判別には1のドライバ固有のエラーコードを使用します。こちらの記事によると、max_execution_timeの設定をオーバーした場合のエラーコードは MySQL 8.0.19 以前は3024か1028で、以降は3024に統一されたとの事です。私の環境はまだMySQL5.7なので、1028のエラーコードも補足する必要があります。これらを考慮して、TimeoutTestControllerの例外処理部分を次の様に修正しました。

app/Http/Controllers/TimeoutTestController.php

...
        } catch (\Exception $e) {
            $timeoutError = false;

            switch (get_class($e)) {
                case TimeoutException::class:
                    $timeoutError = true;
                    break;

                case QueryException::class:
                    if (in_array($e->errorInfo[1], [3024, 1028])) {
                        $timeoutError = true;
                    }
                    break;
            }

            if ($timeoutError) {
                return 'timeout error';
            }

            return 'error';
        }

        return 'success';
    }
}

インスタンスのチェックはswitch文でget_class($e)でクラス名を取得して分岐する様に変更しました。QueryExceptionの場合はerrorInfoでエラーコードもチェックします。クエリ実行中にタイムオーバーとなるように/timeout_test?timeout=7へアクセスしてみて下さい。再度、timeout errorが表示されるはずです。

リファクタリング

これまで説明の為にコントローラ側にタイムアウトエラーのエラー処理のコードを記述してきましたが、DbQueryTimeoutと一緒に色々な箇所で使い回すのでまとめておいた方が良さそうです。という事で、DbQueryTimeout::isTimeoutError()にコードを移しました。

app/Services/DbQueryTimeout.php

...
    // タイムアウトエラー発生？
    public static function isTimeoutError(\Exception $e): bool
    {
        $timeoutError = false;

        switch (get_class($e)) {
            case TimeoutException::class:
                $timeoutError = true;
                break;

            case \Illuminate\Database\QueryException::class:
                if (in_array($e->errorInfo[1], [3024, 1028])) {
                    $timeoutError = true;
                }
                break;
        }

        return $timeoutError;
    }
...

isTimeoutError()はシンプルにタイムアウトエラーか否かを判別するメソッドです。このメソッドを使う事でTimeoutTestController側は次の様にシンプルになりました。

app/Http/Controllers/TimeoutTestController.php

<?php

namespace App\Http\Controllers;

use App\Services\DbQueryTimeout;
use Illuminate\Support\Facades\DB;

class TimeoutTestController extends Controller
{
    public function index()
    {
        $timeout = (int) request('timeout');

        try {
            // 制限時間の指定があればセット
            if ($timeout) {
                DbQueryTimeout::set($timeout);
            }

            // 重いクエリ１
            DB::statement('select sleep(3) union select 1');

            // クエリ以外の処理で3秒掛かった
            sleep(3);

            // 重いクエリ２
            DB::statement('select sleep(5) union select 1');

        } catch (\Exception $e) {
            if (DbQueryTimeout::isTimeoutError($e)) {
                return 'timeout error';
            }

            return 'error';
        }

        return 'success';
    }
}

クエリの累計時間にタイムアウトを設定する（１）

Thu, 27 Jul 2023 11:06:11 +0900

先日、管理サイトにてアラートが発生しました。調査すると、ある検索画面で利用者が重いクエリを連続で発行した事が原因でした。待ち時間が長かった為、不安になり検索ボタンを連打してしまったようです。サーバに負荷を掛ける操作については注意喚起するとして、待ち時間に制限が無いのはよくありません。そこで、検索処理に制限時間を設ける事にしました。今回はそちらの実装にあたって色々学んだことがあるので紹介します。

クエリの実行時間を制限する

今回実装した内容を簡単に説明すると、検索処理に対して実行可能時間を設定し、時間切れとなった場合にエラーを返すというものです、要はタイムアウトの設定です。検索処理においてボトルネックとなっていたのはDBへのクエリ部分で、それ以外の処理時間は無視して良いレベルでした。従って、クエリの実行時間に制限を設ける事にしました。

クエリにタイムアウトを設定する方法については過去の記事の「クエリーの実行所有時間の制限」の項目で紹介されており、今回もこちらを使います。簡単におさらいすると、DB::statement()を使用して、MySQLのmax_execution_timeを設定する方法です。例えば、以下は5秒に制限する場合のコードです。

DB::statement('SET SESSION MAX_EXECUTION_TIME = 5000');

こちらを実行すると、以降クエリで5秒以上掛かった場合にQueryExceptionがスローされます。

クエリの累計時間を制限する

ボトルネックとなるクエリが１つの場合は前項の方法で制限時間を設ければOKですが、今回の実装先には重いクエリが複数実行されており、それらの累計時間を制限する必要がありました。例えば、以下のように制限時間を５秒に設定した場合、クエリ１とクエリ２で合わせて５秒を超えたらタイムアウトエラーとします。

クエリの累計時間に制限を設けるには、クエリを実行する毎に都度残り時間を計算し、それを前項で紹介した方法で設定していけば良さそうです。つまり、以下の様に

クエリ１の時点では残り時間を５秒として制限時間を設定しますが、クエリ２の時点ではクエリ１で３秒掛かったので、残りの実行可能時間２秒を制限時間として再設定します。

DbQueryTimeout.php

ロジックについて理解が深まったところで、実際のコードを紹介します。クエリの制限時間を管理するクラスとして app/Services 配下に DbQueryTimeout.php を追加しました。

app/Services/DbQueryTimeout.php

<?php

namespace App\Services;

use App\Exceptions\TimeoutException;
use Illuminate\Support\Facades\DB;
use Illuminate\Support\Str;

class DbQueryTimeout
{
    const TIMEOUT_QUERY = 'SET SESSION MAX_EXECUTION_TIME';

    public static $maxExecutionTime;  // 最大実行可能時間（ミリ秒）

    public static $processStartTime;  // プロセス開始時刻（マイクロ秒）

    // タイムアウト設定初期化
    public static function set(int $seconds): void
    {
        self::$maxExecutionTime = $seconds * 1000;
        self::$processStartTime = microtime(true);

        DB::beforeExecuting(function ($query) {
            // タイムアウト設定のクエリなら何もしない
            if (Str::startsWith($query, self::TIMEOUT_QUERY)) {
                return;
            }

            // 残りの実行可能時間を計算
            $timeRemaining = self::timeRemaining();

            // 実行可能時間が残っていないなら例外スロー
            if ($timeRemaining <= 0) {
                throw new TimeoutException;
            }

            self::setTimeout($timeRemaining);
        });
    }

    // タイムアウト設定
    public static function setTimeout(int $time): void
    {
        DB::statement(self::TIMEOUT_QUERY.' = '.$time.';');
    }

    // 残りの実行可能時間をミリ秒で返す
    public static function timeRemaining(): int
    {
        return self::$maxExecutionTime - self::elapsedTime();
    }

    // 経過時間をミリ秒で返す
    public static function elapsedTime(): int
    {
        return (int) ((microtime(true) - self::$processStartTime) * 1000);
    }
}

後で説明しますが、このクラス内で使用されている TimeoutException は自作の例外クラスになります。app/Exceptions 配下に TimeoutException.php を追加してください。

app/Exceptions/TimeoutException.php

<?php

namespace App\Exceptions;

use Exception;

class TimeoutException extends Exception
{
}

DbQueryTimeout の使い方はとてもシンプルで、実行時間を制限したい箇所の最初にset()を実行するだけです。set()の引数には制限時間を秒で指定します。例えば、制限時間を５秒としたいなら以下の様に。

DbQueryTimeout::set(5);

すると、set()が実行された時点からカウントダウンが始まり、タイムオーバーとなった場合は以下の２パターンでエラーが発生します。

クエリ実行中
クエリ実行外で、それ以後にクエリを実行しようとした

前者の場合はQueryExceptionがスローされ、後者の場合はTimeoutExceptionがスローされます。

参考までに実装例を掲載します。以下は注文データを検索するページです。

app/Http/Controllers/InvoiceController.php

<?php

namespace App\Http\Controllers;

use App\Models\Invoice;
use App\Models\InvoiceShip;
use Illuminate\Http\Request;
use App\Services\DbQueryTimeout;
use Illuminate\Contracts\View\View;

class InvoiceSearchController extends Controller
{

    /**
     * 検索画面
     */
    public function index(Request $request): View
    {
        $input = $request->all();

        // 制限時間を5秒に設定
        DbQueryTimeout::set(5);

        // 注文データ
        $invoices = Invoice::query()
            ->whereBetween('invoice_date', [$input['date_start'], $input['date_end']])
            ->where('invoice_status', '=', $input['invoice_status'])
            ->orderBy('invoice_date', 'desc')
            ->paginate(config('local.items_per_page'))
            ->withQueryString();

        // 注文配送データ
        $invoice_ships = InvoiceShip::query()
            ->whereIn('invoice_id', $invoices->pluck('invoice_id'))
            ->where('invoice_ship_status', '=', $input['invoice_ship_status'])
            ->get();

        return view('admin.invoice_index')
            ->with(compact('input', 'invoices', 'invoice_ships'));
    }

}

上記のコントローラのindexアクションでは以下の３つのクエリが実行されています。

１ページに表示する注文データ
注文データの件数
注文データに紐づく注文配送データ

これら３つのクエリの累計実行時間が５秒を超える場合はエラーが発生します。エラーが発生した場合の処理については次の投稿で紹介します。

コードのポイント

コア部分であるset()で行われている処理について補足です。set()ではクエリ毎に実行されるbefore処理を登録しています。before処理では以下の処理が実行されます。

実行されるクエリが制限時間の設定クエリなら何もせず、そのまま実行
それ以外のクエリなら残りの実行可能時間を計算
残り時間なし（既にタイムオーバー）ならTimeoutExceptionをスロー
残り時間があるならそれを制限時間として設定

before処理の登録にDB::beforeExecuting()を使用している点がポイントです。こちらはドキュメントには載っていませんが、イベントリスナーの様にEloquentやクエリビルダにてクエリが実行される毎に直前に呼び出すコールバックを登録できます。余談ですが、after処理の登録にはDB::listen()というメソッドがあります。（こちらはドキュメントにも載っている。）

DB::beforeExecuting()のクロージャの引数$queryはSQLが文字列で渡されます。1. 実行されるクエリが制限時間の設定クエリなら何もせず、そのまま実行ではそちらが、SET SESSION MAX_EXECUTION_TIMEから始まるクエリかチェックして、そうならbefore処理を終了しそのままクエリの実行に移ります。そうしなければ、この制限時間を設定するクエリに対しても更にbefore処理をして、、、と無限ループとなってしまうからです。

長くなってしまったので、一旦ここで切ります。次回はエラー処理について解説します。

設定なしでカスタムログファイルを作成（２）

Sat, 17 Jun 2023 04:28:42 +0900

プログラムの中のどこからでもカスタムログを作成できるようにしたのは前回の話。今回はそのログを例えば３ヶ月ごとにローテーションしてみます。

前回のカスタムログの関数はこちらです。

ローテーションの目的

ログのファイルをローテーションする目的は、いくつかあります。１つのファイルにログを保存していると、ファイルが大きくなるのでオープンするのに時間がかかる、また、ファイルが大きくなるとディスクスペースも取られ、最悪はディスク使用率が100%となるかもしれません。ということで、ファイル名に年月を入れて必要な月数だけのファイルをキープするのがログローテーションです。

具体的な例として、現在ディレクトリに以下のようなログファイルがあるとします。

custom-2023-04.log
custom-2023-05.log
custom-2023-06.log

7/1になりログが保存されると、

custom-2023-05.log
custom-2023-06.log
custom-2023-07.log

４月のファイルが削除されて７月のファイルが作成されます。つまりいつも３ヶ月分のログファイルが存在します。

ローテーションするには

Laravelはログの管理には、phpではとても有名なMonologのパッケージを使っています。Monologはとてもフレキシブルに出来ていていろいろなカスタム化が可能です。今回はMonologのログローテーションのハンドラーを使い、月次のローテーションを設定します。

まず、RotatingFileHandlerのクラスを継承して、ファイルフォーマットの設定を、デフォルトの日次FILE_PER_DAYから、月次のFILE_PER_MONTHに設定します。

app/logging/MonthlyRotatingHandler.php

namespace App\Logging;

use Monolog\Handler\RotatingFileHandler;
use Monolog\Logger;

class MonthlyRotatingHandler extends RotatingFileHandler
{
    /**
     * @param  string  $filename　　ログファイル名
     * @param  int  $maxFiles       最高のローテーション数（0ならローテーションなし）
     * @param  string|int  $level   これがコールされる最低のログレベル（デフォルトはDEBUG）
     * @param  bool  $bubble        stackチャンネルが可能か（デフォルトはtrue）
     * @param  int|null  $filePermission ファイルの許可（デフォルトは0644）
     * @param  bool  $useLocking     書き込み中にログファイルをロックするか（デフォルトはfalse）
     */
    public function __construct(string $filename, int $maxFiles = 0, $level = Logger::DEBUG, bool $bubble = true, ?int $filePermission = null, bool $useLocking = false)
    {
        parent::__construct($filename, $maxFiles, $level, $bubble, $filePermission, $useLocking);

        $this->setFilenameFormat('{filename}-{date}', static::FILE_PER_MONTH); // デフォルトの'Y-m-d'から'Y-m'に変える
    }
}

簡単ですね。ちなみに、年次としたいなら、FILE_PER_YEARとしてください。

次に、このハンドラーを使い、前回作成したヘルパーを編集します。

app/helpers.php

use Illuminate\Support\Facades\Log;

if (! function_exists('custom_log')) {
    function custom_log($prefix, $message)
    {
        Log::build([
            'driver'     => 'monolog',
            'handler'    => App\Logging\MonthlyRotatingHandler::class,
            'with'       => [
                'filename'       => storage_path('logs/'.$prefix.'.log'),
                'filePermission' => 0666, //すべてで読み書き可能とする
                'maxFiles'       => 3, // ３ヶ月でローテーション
            ],
        ])->info($message);
    }
}

これだけです。早速テストしてみると、storage/logsには以下のようにファイルが作成されました。

$ ls -l
-rw-rw-rw- 1 kenji kenji 114 Jun 14 14:20 custom-2023-06.log
-rw-rw-rw- 1 kenji kenji   0 Jun 14 14:19 laravel.log

また、上のfilePermissionで指定したように、ファイルのパーミッションは0666となっています。

設定なしでカスタムログファイルを作成（１）

Wed, 07 Jun 2023 09:20:09 +0900

プログラムの中で必要なときにちょろっとある情報をログに残したい、しかもlaravel.logではなくカスタム（ここが大事）のログファイルを作成して残したい、というのが私の願いです。さて、どうプログラムするか？

通常は

以前にも紹介したように、カスタムのログファイルを使うには、config/logging.phpに以下のように追加して、

config/logging.php

...
    'channels' => [
        'single' => [
            'driver' => 'single',
            'path' => storage_path('logs/laravel.log'),
            'level' => 'debug',
        ],
...
       'custom' => [
            'driver' => 'single',
            'path' => storage_path('logs/custom.log'),
            'level' => 'info',
            'permission' => 0666,
        ],
    ],
];

と設定して、

use Illuminate\Support\Facades\Log;
...
Log::channel('custom')->info('テストだよ');

のようにコールすると、storage/logs/custom.logが作成されて渡した文字列が日時とともに記録されます。

しかし、ログファイル名を変えたいなら、いちいちconfig/logging.phpで設定しなればならないのが難点です。

オンデマンドログ

そこで登場するのがオンデマンドのログです。以下のように使います。

use Illuminate\Support\Facades\Log;
... 
Log::build([
    'driver' => 'single',
    'path' => storage_path('logs/custom.log'),
])->info('記録したいことをここに書く');
...

Logをコールするときに、どのファイルに書き込むかなどの設定もその場で指定してしまいます。しかし、今度はタイプする文字数が多いのが難点。

ヘルパーの作成

先の実行文をヘルパーにして、以下のようにコールするようにしたらシンプルになりますね。

custom_log('custom', '記録したいことをここに書く');
// storage/logs/customer.logに保存される
custom_log('invalid_email', '不正なメールアドレス：'.$request->email);
// storage/logs/invalid_email.logに保存される

このヘルパーの関数は、以下のように定義してapp/helpers.phpへ入れます。

app/helpers.php

<?php
use Illuminate\Support\Facades\Log;

if (! function_exists('custom_log')) {
    function custom_log($prefix, $message)
    {
        Log::build([
             'driver' => 'single',
             'path' => storage_path('logs/'.$prefix.'.log'),
        ])->info($message);
    }
}

そして、composer.jsonファイルを編集して、以下のようにautoloadにfilesとして含みます。

composer.json

...
    "autoload": {
        "files": [
            "app/helpers.php"
        ],
        "psr-4": {
            "App\\": "app/",
            "Database\\Factories\\": "database/factories/",
            "Database\\Seeders\\": "database/seeders/"
        }
    },
...

最後に以下を実行してローダーを更新します。

composer dump-autoload

これでLaravelのプログラムのどこでも、customer_log()を使用することができます。

名前付きエラーバッグによるエラー管理

Wed, 24 May 2023 08:56:03 +0900

１つのページに複数のフォームが存在する場合、エラーの管理が煩雑になりがちです。そんな時は名前付きエラーバッグを使ってフォーム毎にエラーを分けると管理しやすいです。

煩雑になってしまう例

複数のフォームがある場合にエラー管理が煩雑になる、とはどんな時でしょうか？例を用いて解説します。

以下の様な会員情報の編集ページがあったとします。

フォームが２つあり、それぞれ別のルートにPOSTされます。

ここでプランナーさんから

「バリデーションエラー発生時に警告文をフォーム毎に文言を変えて表示したい！」

とリクエストが来たとします。つまり、ユーザ情報フォームに関する何かしらのエラーがあれば以下を表示

そして、会社情報フォームに関する何かしらのエラーがあれば以下を表示

何かしらのエラーがあれば、、、と言う条件はフォームが１つであれば簡単で

@if ($errors->any())
... 警告文
@endif

とできますが、フォームが複数ある場合はどうすれば良いでしょうか？ sessionに判別用の値をセットする？それともリダイレクト元のルートで判別する？やり方は色々あると思いますが、名前付きエラーバッグを使うとスマートにできます。

名前付きエラーバッグとは？

その名の通り、エラーバッグに任意の名前を付けたものです。（ここで言うエラーバッグとは、blade側でエラーを参照する際に使う $errors です）

フォーム毎にエラーバッグの名前を分けて付けることで、エラーを分けて管理できるようになります。

エラーバッグに名前をつける

エラーバッグに名前を付けるにはバリデーション時にvalidateWithBag()を使用します。例えば、前項のフォームのバリデーションで以下のようにしています。

ユーザ情報フォーム側では、エラーバッグ名をuserとして第一引数に指定しています。

$validated = $request->validateWithBag(
    'user',                                       // ←エラーバッグ名
    ['name' => 'required'],
    ['name.required' => '名前を入力してください。']
);

会社情報フォーム側では、エラーバッグ名をcompanyとして指定しています。

$validated = $request->validateWithBag(
    'company',                                    // ←エラーバッグ名
    ['company_name' => 'required'],
    ['company_name.required' => '会社名を入力してください。']
);

また、withErrors()を使ってリダイレクトにエラーをセットする際は第二引数にエラーバッグ名を指定します。

return back()->withErrors($validator, 'user')->withInput();

名前付きエラーバッグからエラーを参照する

エラーバッグ名の指定ができたので、今度はblade側でエラーを参照してみましょう。任意の名前のエラーバッグからエラーを参照する際は、 $errors->エラーバッグ名->first(…)などとします。従って、

// ユーザ情報フォームのエラーを取得する場合、
{{ $errors->user->first('name') }}

// 会社情報フォームのエラーを取得する場合、
{{ $errors->company->first('name') }}

// errorディレクティブを使う場合は第二引数にエラーバッグ名を指定
@error('name', 'user')
    {{ $message }}
@enderror

また、前項の警告文の様に、ユーザ情報フォームに何かしらのエラーがあるか判別するには

@if ($errors->user->any())
...
@endif

が使えます。

他の項目に依存する項目のバリデーション

Wed, 15 Mar 2023 06:05:35 +0900

バリデーションの話は尽きないです。過去にもいくつか取り上げました。今回もちょっと頭をひねった話です。

入力例

まずは入力例から、

ユーザーの登録の入力画面で、メルマガの購読をするならドロップダウンで１週間に受信したい回数を指定します。上のキャプチャでは見えないけれど、ドロップダウンで１回、２回、３回の選択が出てきます。メルマガの購読のチェックボックスをオフにしたら、javascriptで回数のドロップダウンの選択を無効としてもいいですね。

この画面の入力値のバリデーションとして、以下のようなコントローラのコードとします。

class DemoController extends Controller
{
    public function create(Request $request)
    {
        $options = [
            0 => '-- 選択してください --',
            1 => '１回',
            2 => '２回',
            3 => '３回',
        ];

        return view('demo2')->with(compact('options'));
    }

    public function store(Request $request)
    {
        $validated = $request->mergeIfMissing([
            'subscribe' => 'N', // メルマガ購読がオフだと値が返ってこないので、ここで値を設定
        ])->validate([
            'email'      => 'required|email',
            'subscribe'  => 'required|in:Y,N', // メルマガ購読？
            'frequency'  => 'required_if:subscribe,Y|integer|in:1,2,3', //購読するなら受信回数をチェック
        ], ['frequency.in' => '選択してください']);

        dd($validated);
    }
}

登録ボタンを押して実行してみましょう！

メルマガ購読のチェックボックスをオン（subscribe = ‘Y’）にしたら、必ず受信回数の選択が必要となり期待通りのエラーが表示されます。上のfrequencyのルールでは、

required_if:subscribe,Yは、「メルマガを購読する」（subscribe = 'Y'）がオンとなり、requiredとなりfrequencyの値（０）があるので正
integerでは、値（０）は整数ゆえに正
in:1,2,3では、値（０）は１でも２でも３でもないので誤

となりエラーです。

さて、今度はメルマガ購読をオフ（subscribe = ‘N’）にして、投稿してみます。

「メルマガを購読する」はオフなのに、どうしてこれもエラーとなるのでしょう？先と違ってrequired_if:subscribe,Yではrequiredとなりませんが、その結果は誤でもありません。しかし最後のルールin:1,2,3では前回と同様に誤となりエラーなります。

その証拠に、今度はメルマガ購読オフで、１回を選択するとエラーとはなりません。

以前習ったbailを使っても同じです。required_if:subscribe,Yのルールの結果が誤となるわけでないので。

            'frequency'  => 'bail|required_if:subscribe,Y|integer|in:1,2,3', //購読するなら受信回数をチェック

exclude_if

一体どうすればよいのでしょうか。そこで登場するのが、exclude_ifのルールです。

            'frequency'  => 'exclude_if:subscribe,N|required_if:subscribe,Y|integer|in:1,2,3', //購読するなら受信回数をチェック

メルマガ購読がオフ（subscribe = ‘N’）なら、exclude_if:subscribe,Nで他のルールは適用されなく、以下のようにエラーとなりません。

nullable

exclude_ifがややこしいと思うなら、これはどうでしょう？

「– 選択してください –」の選択値を０でなくnullとします。また、frequencyのルールにおいて、exclude_ifの代わりにnullableと追加します。

class DemoController extends Controller
{
    public function create(Request $request)
    {
        $options = [
            null => '-- 選択してください --',　// 0でなくnullです。
            1 => '１回',
            2 => '２回',
            3 => '３回',
        ];

        return view('demo2')->with(compact('options'));
    }

    public function store(Request $request)
    {
        $validated = $request->mergeIfMissing([
            'subscribe' => 'N', // メルマガ購読がオフだと値が返ってこないので、ここで値を設定
        ])->validate([
            'email'      => 'required|email',
            'subscribe'  => 'required|in:Y,N', // メルマガ購読？
            'frequency'  => 'nullable|required_if:subscribe,Y|integer|in:1,2,3', // nullableが入っています。
        ], ['frequency.in' => '選択してください']);

        if ($validated['subscribe'] === 'N') {
            $validated['frequency'] = 0; // nullでなく0とする
        }

        dd($validated);
    }
}

匿名関数

まだややこしいと思うならこれはどうでしょう？ルールの匿名関数を使用して「メルマガを購読する」がオンのときだけ値の数字のチェックとしました。

class DemoController extends Controller
{
    public function create(Request $request)
    {
        $options = [
            0 => '-- 選択してください --',
            1 => '１回',
            2 => '２回',
            3 => '３回',
        ];

        return view('demo2')->with(compact('options'));
    }

   public function store(Request $request)
    {
        $validated = $request->mergeIfMissing([
            'subscribe' => 'N',
        ])->validate([
            'email'      => 'required|email',
            'subscribe'  => 'required|in:Y,N',
            'frequency'  => [
                'required_if:subscribe,Y',
                'integer',
                function($attribute, $value, $fail) {
                    if (request('subscribe') === 'Y') {
                        if (! in_array($value, [1,2,3])) {
                            $fail('選択してください');
                        }
                    }
                }
            ]
        ]);

        dd($validated);
    }
}

php8.0 のキャッチアップ - match式

Fri, 24 Feb 2023 07:02:58 +0900

巷ではLaravel 10がリリースされ賑わっていますが、最近私が担当した案件はL9へのUpgradeです。いつもの様にLaravel Shiftが出してくれるPull Requestを眺めていると、見慣れない記法が出てきました。調べてみるとPHP8.0から導入されてた記法でした。

PHP8.0がリリースされて間も無くキャッチアップしたはずなのですが、全く記憶にありません。ということで、再度PHP8.0から導入された機能を復習しました。いくつか取り入れたい記法を見つけたのでご紹介します。今回はmatch式です。

match式

公式マニュアルより抜粋。

$return_value = match (制約式) {
    単一の条件式 => 返却式,
    条件式1, 条件式2 => 返却式,
};

match式はswitch文と似ています。条件とそれにmatchした場合に返却する値を指定します。

switch文と異なり条件にmatchしているか比較する際に"=="ではなく"==="が用いられます。

つまり、

// switch文
$num = '0';

switch ($num) {
    case 0:
        echo "integer zero";
        break;
    case '0':
        echo "string zero";
}

>> integer zero

// match式
$matched = match ($num) {
    0 => "integer zero",
    '0' => "string zero",
};

echo $matched;

>> string zero

因みにmatchは式なので末尾のセミコロンを忘れないように注意です！

複数の条件で同じ値を返す場合やいずれの条件にも当てはまらなかった場合（デフォルト）の書き方はswitch文と似ているので理解しやすいです。

$matched = match ($trafficSignal) {
    'blue', 'green' => 'go',    // blue, green のいずれかなら
    'yellow' => 'caution',
    'red' => 'stop',
    default => 'nothing to do'    // いずれの条件にもmatchしないなら
};

Laravel9から学ぶ活用方法

Laravel9からはPHP8.0以上が要件となった事で、ソースコード内でも色々な箇所で活用されている様です。どの様な使い方をしているのでしょうか？

例えば、Handler.php にて例外がスローされた際のレスポンスをレンダリングしている箇所では

vendor/laravel/framework/src/Illuminate/Foundation/Exceptions/Handler.php

    public function render($request, Throwable $e)
    {
        〜〜省略〜〜

        return match (true) {
            $e instanceof HttpResponseException => $e->getResponse(),
            $e instanceof AuthenticationException => $this->unauthenticated($request, $e),
            $e instanceof ValidationException => $this->convertValidationExceptionToResponse($e, $request),
            default => $this->renderExceptionResponse($request, $e),
        };
    }

前の段落で扱ったサンプルコードではいずれも制約式に変数を渡していましたが、こちらはtrueを指定しています。そして、上から順番にtrueを返す条件式が無いかチェックしていきます。

もし、$eがHttpResponseExceptionのインスタンスなら、$e->getResponse()を実行して結果を返却。それ以外でもし、$eがAuthenticationExceptionのインスタンスなら、$this->unauthenticated($request, $e)を実行して結果を返却。それ以外でもし、、、（以下省略）

これはつまり、従来は if … elseif … で書いていたパターンですね。

実際、Laravel 8まではif文で書かれていた様です。

vendor/laravel/framework/src/Illuminate/Foundation/Exceptions/Handler.php

    public function render($request, Throwable $e)
    {
        〜〜省略〜〜

        if ($e instanceof HttpResponseException) {
            return $e->getResponse();
        } elseif ($e instanceof AuthenticationException) {
            return $this->unauthenticated($request, $e);
        } elseif ($e instanceof ValidationException) {
            return $this->convertValidationExceptionToResponse($e, $request);
        }

        return $this->shouldReturnJson($request, $e)
                    ? $this->prepareJsonResponse($request, $e)
                    : $this->prepareResponse($request, $e);
    }

if … elseif … よりもmatch式を使った書き方の方が行数も少ないし、随分シンプルな印象を受けます。今後の開発時に活用していきたいと思いました。

ブレードコンポーネント（３）チェックボックス

Mon, 26 Dec 2022 08:53:50 +0900

のHTMLタグにおける文字列の入力（type=“text,emailなど”）と違ってチェックボックス（type=“checkbox”）は、値をそのまま表示しません。オン・オフのチェックマークとしてUIで表示する必要あります。また、フォームの投稿の際には、チェックボックスがオフの状態つまりチェックされていない状態だと値もフォームのリクエストに入ってきません。今回は、チェックボックスのコンポーネントの作成の話です。

入力画面

以下のような画面でチェックボックスのコンポーネントx-checkboxを使います。

この画面のブレードはこんな感じです。

<x-layout>
    <div class="container">
      <div class="row justify-content-center">
        <div class="col-md-8">
          <div class="card">
            <div class="card-header">登録</div>

            <div class="card-body">
              <x-form action="{{ route('checkbox') }}">

                <div class="row mb-3">
                  <x-label name="email">メールアドレス</x-label>
                  <div class="col-md-6">
                    <x-input type="email" name="email" required autocomplete="email"  />
                  </div>
                </div>

                <div class="row mb-3">
                  <x-label name="dummy"></x-label>
                  <div class="col-md-6">
                    <x-checkbox name="subscribe" value="Y">メルマガを購読する</x-checkbox>
                  </div>
                </div>

                <div class="row mb-0">
                  <div class="col-md-6 offset-md-4">
                    <x-button type="submit" class="m-2" level="primary">登録</x-button>
                  </div>
                </div>
              </x-form>
            </div>
          </div>
        </div>
      </div>
    </div>
  </x-layout>

フォームでバリデーションエラーが起こったとき

先の画面でバリデーションのエラーが起こった時は、以下のように、ユーザーが選択したチェックの状態を保つ必要あります。

そのためには、inputにおけるcheckedの属性の表示を、以下のようにold()と$valueの値で比較すればいいですね。

checkbox.blade.php

props([
    'name',
    'value',
    'checked' => 'false',
])
<div class="form-check">
  <input
      type="checkbox"
      id = "{{ $name }}"
      name="{{ $name }}"
      value="{{ $value }}"
      {{ old($name) == $value ? 'checked' : '' }}
      {{ $attributes->merge(['class' => 'form-check-input']) }}
  >
  <label class="form-check-label" for="{{ $name }}">{{ $slot }}</label>
</div>

投稿時のチェックがオンなら、値のYが返されるので、old(‘subscribe’) = ‘Y’となり、$valueの’Y’と同じで、checkedが属性となりエラー表示の画面ではチェックはオンになります。反対に、チェックがオフなら、何も値がないので、old(‘subscribe’) = nullとなり、checkedの属性は表示されなく、エラー表示の画面ではチェックはオフになります。

初期画面のデフォルト

さて、先の画面では、できればメルマガを受け取ってもらいたいので、チェックボックスをわざわざオンにしてもらうのではなく、最初からチェックをオンにして表示したいです。

デフォルトとしてチェックボックスをオンとするには、ブレードで以下のようにcheckedを指定します。

<x-checkbox name="subscribe" value="Y" :checked="true">メルマガを購読する</x-checkbox>

checkedはコンポーネントのプロパティなので、コンポーネントの属性としては、:checkedにphpの式を文字列で指定します。指定している"true"も文字列ではなくブーリアンのtrueとしてコンポーネントに渡されます。ちなみに、以下も同じ結果となります。

<x-checkbox name="subscribe" value="Y" :checked="1=1">メルマガを購読する</x-checkbox>

デフォルトをオフとしたいなら、最初のように:checkedを指定しません。コンポーネントにおいて、‘checked’ => falseとしているので、自動的にfalseとなります。もちろん、以下のように、“false"を渡してもOKです。

<x-checkbox name="subscribe" value="Y" :checked="false">メルマガを購読する</x-checkbox>

同様に、これが新規画面でなく編集画面なら、以下のようにDBからの値を使用し反映できます。

<x-checkbox name="subscribe" value="Y" :checked="$member->subscribe == 'Y'">メルマガを購読する</x-checkbox>

ブレードコンポーネント（２）配列の入力の対応

Sun, 18 Dec 2022 04:56:15 +0900

前回の例はメールアドレス１つの入力でしたが、今度はちょっと複雑にして複数のメールアドレスを入力する配列入力の話です。

入力画面

画面はこんな感じです。

そして、その画面のブレードはこんなです。前回で定義したx-inputのコンポーネントを使用しています。

<x-layout>
  <div class="container">
    <div class="row justify-content-center">
      <div class="col-md-8">
        <div class="card">
          <div class="card-header">登録</div>

          <div class="card-body">
            <x-form action="{{ route('register') }}">

            @for($i=1;$i <=3;$i++)
              <div class="row mb-3">
                <x-label name="email{{ $i }}">メールアドレス {{ $i }}</x-label>

                <div class="col-md-6">
                  <x-input id="email{{ $i }}" type="email" name="emails[{{ $i }}]" />
                </div>
              </div>
            @endfor

              <div class="row mb-0">
                <div class="col-md-6 offset-md-4">
                  <x-button type="submit" class="m-2" level="primary">登録</x-button>
                </div>
              </div>
            </x-form>
          </div>
        </div>
      </div>
    </div>
  </div>
</x-layout>

前回と違って、name=“emails[1]"のように配列の文字列となっていることに注意を。

なにかがおかしい！

上の画面で以下のようにEメールでない値を入れて「登録」ボタンを押すと、

もちろん、画面ではエラーが表示されることを期待しますが、何もでてきません。しかも、入力した値は空になってしまいます。まさに、最初の空の入力画面と同じ状態です。

ちなみに、バリデーションのルールは以下です。

'emails'   => ['required', 'array'],
'emails.*' => ['string', 'email', 'max:255'],

何がおかしいのでしょう？

ここで、前回のx-inputのコンポーネントをここで再度掲載します。

input.blade.php

@props([
    'type'  => 'text',
    'name',
    'value' => null,
])
 
<input
  type="{{ $type }}"
  name="{{ $name }}"
  value="{{ old($name, $value) }}"
 
  @error($name)
    {{ $attributes->class('form-control is-invalid') }}
  @else
    {{ $attributes->class('form-control') }}
  @enderror
/>
 
@error($name)
  <span class="invalid-feedback" role="alert">
      <strong>{{ $message }}</strong>
  </span>
@enderror

調査すると、問題はコンポーネントにおける、old($name, $value)と@error($name)に渡している$nameの値です。

配列なので、この$nameには、emails[1]、emails[2]、emails[3]の文字列が入ってきます。しかし、old()はこれらの文字列を理解しません。@errorに関しては、debugbarでセッションを見ると、以下のように、emails[1]ではなく、emails.1という文字列になっています。

対応

ということは、old()や@error()に渡す指標が配列の文字列なら、ドットの文字列に変換すればよいですね。以下は、改良したコンポーネントです。

@props([
    'type'  => 'text',
    'name',
    'value' => null,
])
@php
  $index = str_replace(['.', '[]', '[', ']'], ['_', '', '.', ''], $name); // 'emails[1]'が'emails.1'となる
@endphp
<input
  type="{{ $type }}"
  name="{{ $name }}"
  value="{{ old($index, $value) }}"

  @error($index)
    {{ $attributes->class('form-control is-invalid') }}
  @else
    {{ $attributes->class('form-control') }}
  @enderror
/>

@error($index)
  <span class="invalid-feedback" role="alert">
      <strong>{{ $message }}</strong>
  </span>
@enderror

これで再度「登録」ボタンを押すと、期待通りにエラーが表示されます。

ブレードコンポーネント

Sun, 11 Dec 2022 12:05:35 +0900

今回は、VueJSのコンポーネントの話ではありません。Inertiaの話でもありません。Laravelのブレードコンポーネントの話です。使い始めると結構いいものです。

デモ

こんな入力画面あるとします。

もともとのブレードは、こんな感じです。

...
<div class="card-body">
    <form method="POST" action="{{ route('register') }}">
        @csrf

        <div class="row mb-3">
            <label for="email" class="col-md-4 col-form-label text-md-end">メールアドレス</label>

            <div class="col-md-6">
                <input id="email" type="email" class="form-control @error('email') is-invalid @enderror" name="email" value="{{ old('email') }}" required autocomplete="email" autofocus>

                @error('email')
                    <span class="invalid-feedback" role="alert">
                        <strong>{{ $message }}</strong>
                    </span>
                @enderror
            </div>
       </div>

       <div class="row mb-0">
            <div class="col-md-6 offset-md-4">
                <button type="submit" class="btn btn-primary">
                    登録
                </button>
            </div>
        </div>
    </form>
</div>
...

今度は、コンポーネントを使用した、ブレードファイルの中身を見てみましょう。

...
<div class="card-body">
    <x-form action="{{ route('register') }}">

        <div class="row mb-3">
            <x-label name="email">メールアドレス</x-label>

            <div class="col-md-6">
                <x-input type="email" name="email" required autocomplete="email"  />
            </div>
        </div>

        <div class="row mb-0">
            <div class="col-md-6 offset-md-4">
                <x-button type="submit" level="primary">登録</x-button>
            </div>
        </div>
    </x-form>
</div>
...

見た目、とてもシンプルになりました。しかし、見慣れないHTMLタグがx-form, x-label, x-input, x-buttonと４つありますね。もちろんそれらがコンポーネントなのですが、どうやってそれらのタグが利用できるようになるのでしょうか？　

コンポーネントの作成

コンポーネントの作成には、２つ方法があり、app/View/Componentsのディレクトリ下にクラスファイルを作成する方法と、resources/views/componentsに匿名コンポーネントを作成する方法があります。ここでは使いやすい後者を紹介します。

先のデモの４つのコンポーネントは、以下のようなファイルに定義されています。

resources/views/components
├── button.blade.php
├── form.blade.php
├── input.blade.php
└── label.blade.php

button.blade.phpというコンポーネントブレードファイルを作成すれば、それだけで、他のブレードファイルで、のタグとして使用可能になります。

コンポーネントの定義

まずは、一番外側のx-formの定義です。

form.blade.php

@props([
    'method' => 'POST',
    'action',
])

@php
  $method = Str::upper($method);
@endphp

<form
  method="{{ $method ===  'GET' ? 'GET' : 'POST' }}"
  action="{{ $action }}"
  {{ $attributes }}>
  @csrf

  @if (! in_array($method, ['GET', 'POST']))
    @method($method)
  @endif

  {{ $slot }}

</form>

御覧のように、通常のブレードファイルと同じように、@ifや@phpが使えます。しかし、@propsは見たことありませんね。

@propsでは、コンポーネントを使用するブレードから、コンポーネントにデータを渡すための変数の宣言と初期化をします。

ここでは、methodとactionの変数がありますが

<x-form action="{{ route('register') }}">

では、actionにしかデータを渡していません。しかし、@propsにおいてmethodのデフォルトはPOSTと指定されているので、実際に出力されるHTMLは、以下のように初期化されます。

<form method="POST" action="http://localhost/register">
<input type="hidden" name="_token" value="8GdTncryczY6s2gkHCMFYJyRlvab2tkLbVp9iRUE">
..
</form>

もう１つ重要なのは、{{ $slot }}です。そこの部分には、とのタグの間の値がすべて渡されます。

x-labelでも同様に{{ $slot }}を使います。

label.blade.php

@props([
    'name',
])

<label for="{{ $name }}" class="col-md-4 col-form-label text-md-end">{{ $slot }}</label>

x-buttonも同様です。

button.blade.php

@props([
    'type'  => 'button',
    'level' => 'default',
])

<button type="{{ $type }}" {{ $attributes->class("btn btn-$level")}}>{{ $slot }}</button>

@attributes->classは、既存のclassの属性に引数のclassをマージします。例えば、

<x-button type="submit" class="m-2" level="primary">登録</x-button>

なら、

<button type="submit" class="btn btn-primary m-2">登録</button>

となります。

最後に、x-inputの定義です。

input.blade.php

@props([
    'type'  => 'text',
    'name',
    'value' => null,
])

<input
  type="{{ $type }}"
  name="{{ $name }}"
  value="{{ old($name, $value) }}"

  @error($name)
    {{ $attributes->class('form-control is-invalid') }}
  @else
    {{ $attributes->class('form-control') }}
  @enderror
/>

@error($name)
  <span class="invalid-feedback" role="alert">
      <strong>{{ $message }}</strong>
  </span>
@enderror

以下のようにコンポーネントで定義していない属性（requiredやautocomplete）も渡していますが、

<x-input type="email" name="email" required autocomplete="email"  />

これらは、そのまま最終のHTMLに渡されます。

<input type="email" name="email" value="" class="form-control" required autocomplete="email">

DBテーブルをjoinして値を更新

Sun, 16 Oct 2022 11:57:03 +0900

これまた、データベースの話ですが、長期でアクティブに管理しているプロジェクトでは必ず登場してくる作業です。

どういうときに必要？

例えば、以下のようなデータの会員テーブル(users)があります。

id	name	rank
1	高橋美加子	A
2	浜田太一	B
3	中島充	A
4	渚あすか	B
5	渚和也	A

最後の項目は、会員ランクで過去２年間に会員が購入した商品の送金額により会員ランクが決まります。会員ランクには、ＡとＢの２つあり、会員ランクＡの会員は、購入の際に5%の割引があるなどの恩恵があります。Ｂランクの会員は残念ながら恩恵なしです。

さて、会員数も増えてきて、Ａランク会員が多すぎて購入額の総額も同じランクでばらつきがあることから、ランクを１つ増やすことにします。つまり、今度はＡ，Ｂ，Ｃと３つのランクとなります。

もちろん、Artisanコマンドを作成して新たなランク計算式を使い、usersのそれぞれのレコードを更新することも可能ですね。こんな感じで。

User::all()->each(function($user) {
    $user->rank = $user->calcNewRank();
    $user->save();
})

しかし、これではもとのランクの値がなんであったか残りません。更新前に、usersのテーブルをdumpしてファイルとして残してもよいですが、もしかしたら、移行後にも旧のランク値はクレームときのために必要かもしれません。

値の移行のためのテーブルを新規に作成

このようなときは、まず、一時的に使用するテーブルを作成して、そこでusersのそれぞれのレコードに対応する旧と新のランクをあらかじめレコードを作成します。テーブル名は、change_rankとして以下のようなデータとなります。

user_id	name	old_rank	new_rank
1	高橋美加子	A	A
2	浜田太一	B	C
3	中島充	A	B
4	渚あすか	B	C
5	渚和也	A	B

change_rankのテーブルとusersのテーブルは、両者のプライマリーキー(users.idとchange_rank.user_id)を介してまったく１対１の関係となり、後の一括更新に使用されます。さらに、この移行のテーブルを残しておけば、旧と新のランク値のスナップショットとなり、何かのときにとても有用なものとなります。

一括更新

通常更新は、１つのテーブルにおいて、例えば以下のように更新します。

UPDATE users SET rank = 'A';

しかし、今回のケースは２つのテーブルが関わる、つまり１つのテーブルの値をもとにもう１つのテーブルの値の更新となるので、joinが必要となります。SQL文では以下のようになります。

UPDATE users
INNER JOIN change_rank ON users.id = change_rank.user_id
SET user.rank = change_rank.new_rank;

さて、これをSQL文でなく、クエリビルダーで行うなら、以下のようなコードとなります。

DB::table('users')
    ->join('change_rank', 'users.id', '=', 'change_rank.user_id')
    ->update(['users.rank' => DB::raw('change_rank.new_rank')]);

ここ以下のように書いてしまいそうですが、DB::raw()がないとエラーとなるので注意を。

DB::table('users')
    ->join('change_rank', 'users.id', '=', 'change_rank.user_id')
    ->update(['users.rank' => change_rank.new_rank]);

EloquentとQuery Builderのvalue()の違い

Tue, 26 Jul 2022 23:31:57 +0900

Eloquentでクエリする際も内部的にはクエリビルダのメソッドをcallしている事が多いので、何も考えずにクエリビルダで出来ていた事をそのままEloquentで実行していたらハマってしまいました、落とし穴に。おかげで「なるほど、そういう事もあるのだな」位の心構えができるようになりました。今回はそんな気づきを与えてくれたvalue()についての解説です。

value()とは？

value()はクエリの最初の結果から特定の項目のみ取得して返してくれる便利なメソッドです。DBからfetchするレコードが１つだと分かっていて、且つ、特定の１項目のみが必要な場合などに重宝します。

例えば、ユーザの名前と生年月日の組み合わせがユニークであり、そのemailを取得したい場合は

$email = DB::table('user')
    ->where('name', '=', '山田太郎')
    ->where('birthday', '=', '1970-01-01')
    ->value('email');
>>> "y.taro@sample.com"

と書けば一発で取得できます。上記はクエリビルダでの取得ですが、Eloquentでも同様にvalue()を使うことが出来ます。

$email = User::query()
    ->where('name', '=', '山田太郎')
    ->where('birthday', '=', '1970-01-01')
    ->value('email');
>>> "y.taro@sample.com"

いずれも実行されるsqlは以下の通り、

select `email` from `member` where `name` = '山田太郎' and `birthday` = '1970-01-01' limit 1;

特定の項目のみselectしつつ、limitで取得する結果を１つに限定している点がポイントです。

こうしてみると、クエリビルダとEloquentのvalue()は一見同じ処理を行っているように見えますね。しかし、次の例では異なる結果を返します。

私がハマった落とし穴

以下ではとあるブログの投稿(post)に紐付いたタグ名(tag.name)を取得しGROUP_CONCATで連結して取得しました。

$tags = DB::table('post')
    ->join('tag', 'post.post_id', '=', 'tag.post_id')
    ->where('post.post_id', '=', 1)
    ->groupBy('post.post_id')
    ->value(DB::raw('GROUP_CONCAT(tag.name)'));
>> "Laravel,PHP,Eloquent"

クエリビルダではカンマで連結されたタグ名が取得できました。 Eloquentではどうでしょうか？

$tags = Post::query()
    ->join('tag', 'post.post_id', '=', 'tag.post_id')
    ->where('post.post_id', '=', 1)
    ->groupBy('post.post_id')
    ->value(DB::raw('GROUP_CONCAT(tag.name)'));
>> null

あれれ、どういう訳かnullが返されました。

ソースを解析

以下はEloquentのvalue()のソースコードです。

vendor/laravel/framework/src/Illuminate/Database/Eloquent/Builder.php

/**
 * Get a single column's value from the first result of a query.
 *
 * @param  string|\Illuminate\Database\Query\Expression  $column
 * @return mixed
 */
public function value($column)
{
    if ($result = $this->first([$column])) {
        return $result->{Str::afterLast($column, '.')};
    }
}

なるほど、first([$column])でクエリ結果を取得し、$columnで指定した値のコロン（’.’）以降をプロパティ名としてアクセスしています。

つまり先ほどの例だと、$columnはGROUP_CONCAT(tag.name)なので、コロン以降はname)となります。従って、Undefined propertyとして処理され、nullとなった訳です。

一方、結果が正しく取得できたクエリビルダはというと、

vendor/laravel/framework/src/Illuminate/Database/Query/Builder.php

/**
 * Get a single column's value from the first result of a query.
 *
 * @param  string  $column
 * @return mixed
 */
public function value($column)
{
    $result = (array) $this->first([$column]);

    return count($result) > 0 ? reset($result) : null;
}

配列に変換した上で、reset()を使って１つ目の結果を取得していました。

回避策

回避策は色々ありそうですが、私の中では生クエリ（DB::raw）とvalue()を併用したい場合は一度selectRaw()などで別名を付けるルールを採用する事にしました。

$tags = Post::query()
    ->join('tag', 'post.post_id', '=', 'tag.post_id')
    ->where('post.post_id', '=', 1)
    ->groupBy('post.post_id')
    ->selectRaw('GROUP_CONCAT(tag.name) AS tag_names')
    ->value('tag_names');
>> "Laravel,PHP,Eloquent"

現場からは以上です。

toArray()でcreated_at,updated_atのフォーマットが変わる

Tue, 28 Jun 2022 09:46:39 +0900

Eloquentモデルを配列に変換して渡す必要がある際にたまに使うtoArray()ですが。先日何気なく使用していて思わぬエラーに遭遇、原因を調べてみると実はLaravel 7.xから変更されていた仕様でした。Upgrade Guideには目を通していたつもりでしたが、どうしてなかなか行き当たりばったりなキャッチアップになってしまう、Lazy Loadingな私です。

$user->toArray()

まず、toArray()を使用していて遭遇したエラーについて説明します。 Laravelインストール後にデフォルトで存在するUserモデルをtoArray()で変換してみましょう。

// factory でダミーレコード生成
>>> $user = User::factory()->create();
=> App\Models\User {#3575
     name: "Mr. Buck Schinner MD",
     email: "waters.montana@example.com",
     email_verified_at: "2022-06-05 04:34:30",
     #password: "$2y$10$92IXUNpkjO0rOQ5byMi.Ye4oKoEa3Ro9llC/.og/at2.uheWG/igi",
     #remember_token: "wp5fKxXY7s",
     updated_at: "2022-06-05 04:34:30",
     created_at: "2022-06-05 04:34:30",
     id: 1,
   }

>>> $user->toArray();
=> [
     "name" => "Mr. Buck Schinner MD",
     "email" => "waters.montana@example.com",
     "email_verified_at" => "2022-06-05T04:34:30.000000Z",
     "updated_at" => "2022-06-05T04:34:30.000000Z",
     "created_at" => "2022-06-05T04:34:30.000000Z",
     "id" => 1,
   ]

お気づきでしょうか？ email_verified_at, updated_at, created_at の日付形式がY-m-d H:i:sからISO-8601に変換されています。

なぜでしょうか？

日付のフォーマット

これはLaravel 7から内部的にCarbonのtoJson()を使用するようになったためのようです。

https://laravel.com/docs/7.x/upgrade#date-serialization

確かに、CarbonでtoJson()を使用するとISO-8601形式で日付が出力されますね。

Carbon::today()->toJson();
=> "2022-06-05T00:00:00.000000Z"

とは言え、全てのdatetimeやtimestamp型の項目がフォーマットされるわけではなく、デフォルトではcreated_atとupdated_atのみです。その他の項目についてはemail_verified_atの様に、$castsにてdatetimeを指定すると同様にISO-8601形式でフォーマットされます。

デフォルトのフォーマットを変更する

今回私が遭遇したケースではcreated_atとupdated_atをY-m-d H:i:sの形式のまま配列に変換する必要がありました。 toArray()で変換する際に日付のフォーマットを指定するにはどうすれば良いでしょう？

$casts

１つはemail_verified_atの様に$castsにて個別に指定する方法です。以下の様に、datetime:に続いて出力したいフォーマットを指定することができます。

app/Models/User.php

...
    /**
     * The attributes that should be cast to native types.
     *
     * @var array
     */
    protected $casts = [
        'email_verified_at' => 'datetime',
        'created_at'        => 'datetime:Y-m-d H:i:s',    // ←日付の形式を指定
        'updated_at'        => 'datetime:Y-m-d H:i:s',    // ←日付の形式を指定
    ];
...

tinkerで出力を確認してみましょう。

>>> $user->toArray();
=> [
     "id" => 1,
     "name" => "Dr. Wanda Gottlieb",
     "email" => "brenda39@example.com",
     "email_verified_at" => "2022-03-09T13:55:28.000000Z",
     "created_at" => "2022-03-09 13:55:28",
     "updated_at" => "2022-03-09 13:55:28",
   ]

正しく反映されていますね。

serializeDate

もう１つはserializeDate()をオーバーライドすることです。このメソッドはModelクラスがuseしているtraitのHasAttributesに定義されており、toArray()実行時に内部的に呼び出されています。このメソッドをオーバーライドすることでcreated_atとupdated_atを含めdatetimeにキャストしている項目のtoArray(), toJson()時のデフォルトのフォーマットを指定できます。フォーマットは以下の様にformat()で指定します。

app/Models/User.php

...
use DateTimeInterface;
...
    /**
     * Prepare a date for array / JSON serialization.
     *
     * @param  \DateTimeInterface  $date
     * @return string
     */
    protected function serializeDate(DateTimeInterface $date)
    {
        return $date->format('Y-m-d H:i:s');
    }
...

因みに、serializeDate()で指定しているのはデフォルトのフォーマットなので、$castsでのフォーマット指定と併用した場合は$casts側の指定が優先されます。以下は併用した例です。

app/Models/User.php

...
    /**
     * The attributes that should be cast to native types.
     *
     * @var array
     */
    protected $casts = [
        'email_verified_at' => 'datetime:Y-m-d',    // 日付のみに指定してみる
    ];
...

toArray()すると、created_at, updated_atはY-m-d H:i:sですが、email_verified_atはY-m-dのみの出力となります。

>>> $user->toArray();
=> [
     "id" => 1,
     "name" => "Dr. Wanda Gottlieb",
     "email" => "brenda39@example.com",
     "email_verified_at" => "2022-03-09",    // Y-m-d のみ
     "created_at" => "2022-03-09 13:55:28",
     "updated_at" => "2022-03-09 13:55:28",
   ]

Commandにbefore/after処理を追加する

Mon, 16 May 2022 07:56:30 +0900

今のプロジェクトでは独自に作成したコンソールコマンドが40~50個ほどあります。バッチ処理であったり、クロンで定期実行している処理であったりと様々です。システムが大きくなるとそれだけ必要な処理が増えるので致し方ありません。しかし時折、

このコマンドは何をやっているんだっけ？と見返した時にすぐ思い出せるようにコード量を少なく、シンプルに保っておきたいものです。

そう思いながら今まで作成したコマンドらを眺めていると、毎回決り文句のように記述している処理がいくつかある事に気づきました。気づいてしまったが故にDRYアレルギーが発症してしまい、どこか適切な場所に共通処理として切り出せないだろうか？と調べてみると、CommandにはEventが用意されていました。

CommandのEvent

公式ドキュメントの"Artisan Console"ページの最後に少しだけCommandのEventに関する説明があります。それによると、Commandが実行される際は以下の３つのイベントが発行されるそうです。

ArtisanStarting: artisan実行開始時
CommandStarting: Commandが実行される直前、つまりbefore処理
CommandFinished: Commandが実行された後、つまりafter処理

デフォルトでは上記のEventに対するListenerは用意されていないので、新たに作成し紐付ける必要があります。

before/after処理を追加

ここでは例として、CommandStartingイベントとCommandFinishedイベントを使いコマンド実行前と後に処理を追加してみましょう。まずはbefore処理から。

CommandStartingListener作成

before処理を実装する為のListenerクラスを作成します。以下のコマンドを実行。

php artisan make:listener CommandStartingListener

CommandStartingListenerクラスのhandle()にbefore処理を追加します。以下では開始ログを出力してみました。

app/Listeners/CommandStartingListener.php

<?php

namespace App\Listeners;

use Illuminate\Support\Facades\Log;

class CommandStartingListener
{
    /**
     * Handle the event.
     *
     * @param  object  $event
     * @return void
     */
    public function handle($event)
    {
        // 開始ログを出力
        Log::info($event->command."を開始しました。");
    }
}

EventとListenerを紐付け

作成したCommandStartingListenerはそのままでは発火されません。EventServiceProviderにてCommandStartingイベントに紐付けましょう。

app/Providers/EventServiceProvider.php

<?php

namespace App\Providers;

use Illuminate\Auth\Events\Registered;
use Illuminate\Auth\Listeners\SendEmailVerificationNotification;
use Illuminate\Foundation\Support\Providers\EventServiceProvider as ServiceProvider;

class EventServiceProvider extends ServiceProvider
{
    /**
     * The event listener mappings for the application.
     *
     * @var array
     */
    protected $listen = [
        Registered::class => [
            SendEmailVerificationNotification::class,
        ],
        // CommandStartingイベントにリスナを紐付け
        \Illuminate\Console\Events\CommandStarting::class => [
            \App\Listeners\CommandStartingListener::class,
        ],
    ];

    /**
     * Register any events for your application.
     *
     * @return void
     */
    public function boot()
    {
        //
    }
}

同様の手順でCommandFinishedListenerを作成し、CommandFinishedイベントに紐付け、終了ログを出力してみましょう。EventServiceProviderは最終的に以下のようになります。

app/Providers/EventServiceProvider.php

...
    /**
     * The event listener mappings for the application.
     *
     * @var array
     */
    protected $listen = [
        Registered::class => [
            SendEmailVerificationNotification::class,
        ],
        // CommandStartingイベントにリスナを紐付け
        \Illuminate\Console\Events\CommandStarting::class => [
            \App\Listeners\CommandStartingListener::class,
        ],
        // CommandFinishedイベントにリスなを紐付け
        \Illuminate\Console\Events\CommandFinished::class => [
            \App\Listeners\CommandFinishedListener::class,
        ],
    ];
...

最後に

適当なコマンドを実行しログ出力されているか試してみましょう。以下ではルートのリストを出力するコマンドを実行しています。

php artisan route:list

laravel.logに開始と終了のログが出力されましたね。

storage/logs/laravel.log

[2022-05-08 08:21:18] local.INFO: route:listを開始しました。  
[2022-05-08 08:21:18] local.INFO: route:listを終了しました。

【Under the hood】url.intendedはいつどこでセットされたのか？

Wed, 04 May 2022 07:59:30 +0900

前回の記事、ログイン後のリダイレクト先、その２では未ログインの状態でログインが必要なページにアクセスした場合、ログインページへ飛ばされ、ログインすると元々アクセスしたかったページへリダイレクトされる挙動について確認し、sessionのurl.intendedにセットされた値によってログイン後のリダイレクト先が決定する事が理解できました。しかし、url.intendedは一体いつどこでsessionにセットされたのでしょうか？気になったので処理を追ってみました。

注意

今回の記事に掲載しているソースコードはLaravel8から引用しました。Laravel9ではPHP8.0の記法が導入され一部異なりますが行っている処理は同じなのでそちらを使う場合でも参考になるかと思います。

Illuminate\Auth\Middleware\Authenticate.php

ルートのmiddlewareにauthを指定すると、そのページにリクエストが投げられた際にこのクラスのauthenticate()が実行されます。まずはここから見ていきましょう。このメソッドでは$this->auth->guard($guard)->check()にてユーザがログイン済みか否かを確認し、未ログインであればその後の$this->unauthenticated($request, $guards);が実行されます。unauthenticatedはAuthenticationExceptionをスローします。

vendor/laravel/framework/src/Illuminate/Auth/Middleware/Authenticate.php

    /**
     * Determine if the user is logged in to any of the given guards.
     *
     * @param  \Illuminate\Http\Request  $request
     * @param  array  $guards
     * @return void
     *
     * @throws \Illuminate\Auth\AuthenticationException
     */
    protected function authenticate($request, array $guards)
    {
        if (empty($guards)) {
            $guards = [null];
        }

        foreach ($guards as $guard) {
            if ($this->auth->guard($guard)->check()) {    // ログイン済みかチェック
                return $this->auth->shouldUse($guard);
            }
        }
        $this->unauthenticated($request, $guards);    // 未ログインならこちらを実行
    }

    /**
     * Handle an unauthenticated user.
     *
     * @param  \Illuminate\Http\Request  $request
     * @param  array  $guards
     * @return void
     *
     * @throws \Illuminate\Auth\AuthenticationException
     */
    protected function unauthenticated($request, array $guards)
    {
        throw new AuthenticationException(    // 専用の例外をスロー
            'Unauthenticated.', $guards, $this->redirectTo($request)
        );
    }

Illuminate/Foundation/Exceptions/Handler.php

Laravelの全ての例外はApp\Exceptions\Handlerクラスにて処理されます。実際に実行される処理は親クラスである、Illuminate\Foundation\Exceptions\Handlerクラスに定義されています。例外をHTTPレスポンスに変換するrender()を見てみると、AuthenticationExceptionが投げられた場合の処理が記述されています。

vendor/laravel/framework/src/Illuminate/Foundation/Exceptions/Handler.php

    /**
     * Render an exception into an HTTP response.
     *
     * @param  \Illuminate\Http\Request  $request
     * @param  \Throwable  $e
     * @return \Symfony\Component\HttpFoundation\Response
     *
     * @throws \Throwable
     */
    public function render($request, Throwable $e)
    {
        ...

        if ($e instanceof HttpResponseException) {
            return $e->getResponse();
        } elseif ($e instanceof AuthenticationException) {
            return $this->unauthenticated($request, $e);    // ←AuthenticationExceptionが投げられた場合の処理
        } elseif ($e instanceof ValidationException) {
            return $this->convertValidationExceptionToResponse($e, $request);
        }

        ...
    }

そして、同じクラス内のunauthenticated()を呼び出しています。

vendor/laravel/framework/src/Illuminate/Foundation/Exceptions/Handler.php

    ...

    /**
     * Convert an authentication exception into a response.
     *
     * @param  \Illuminate\Http\Request  $request
     * @param  \Illuminate\Auth\AuthenticationException  $exception
     * @return \Symfony\Component\HttpFoundation\Response
     */
    protected function unauthenticated($request, AuthenticationException $exception)
    {
        return $this->shouldReturnJson($request, $exception)
                    ? response()->json(['message' => $exception->getMessage()], 401)
                    : redirect()->guest($exception->redirectTo() ?? route('login'));
    }

    ...

ajaxリクエストの場合はjsonレスポンスを返し、そうでない場合は、redirect()->guest(…)が実行されます。

Illuminate\Routing\Redirector

guest()はコメントにある通り、カレントのURLをセッションにセットしリダイレクトレスポンスを作成します。このカレントのURLというのがアクセスしようとしていたURLの事であり、setIntendedUrl()によってsessionのurl.intendedにセットされるのです。

vendor/laravel/framework/src/Illuminate/Routing/Redirector.php

    /**
     * Create a new redirect response, while putting the current URL in the session.
     *
     * @param  string  $path
     * @param  int  $status
     * @param  array  $headers
     * @param  bool|null  $secure
     * @return \Illuminate\Http\RedirectResponse
     */
    public function guest($path, $status = 302, $headers = [], $secure = null)
    {
        $request = $this->generator->getRequest();

        $intended = $request->method() === 'GET' && $request->route() && ! $request->expectsJson()    // ←カレントURLを取得
                        ? $this->generator->full()
                        : $this->generator->previous();

        if ($intended) {
            $this->setIntendedUrl($intended);
        }

        return $this->to($path, $status, $headers, $secure);
    }

    ...
    /**
     * Set the intended url.
     *
     * @param  string  $url
     * @return void
     */
    public function setIntendedUrl($url)
    {
        $this->session->put('url.intended', $url);    // sessionのurl.intendedにセット
    }

url.intendedは色々なクラスの色々なメソッドを介して最終的にセットされているため、少し複雑でしたが処理の流れを把握できてスッキリしました。お疲れさまでした。

ログイン後のリダイレクト先、その２

Tue, 03 May 2022 07:55:47 +0900

前回の記事ではログインボタンからログインした場合について解説しました。そちらのケースでは、RouteServiceProvider::HOMEを任意の値に変更する事でリダイレクト先を指定できました。今回はもう少し掘り下げ、ログインが必要なページにアクセスし強制的にログインページに飛ばされた場合について見てみましょう。

ログインページへ強制リダイレクト、からのログイン

未ログインの状態でログインが必要なページに遷移するとアクセスがガードされログインフォームに飛ばされますが、そこからログインした場合はどこにリダイレクトするでしょうか？前回の記事でRouteServiceProvider::HOMEに設定したトップページ（’/’）でしょうか？確認してみましょう。

以下のようにweb.phpを編集して’sayhi’というrouteを追加します。

routes/web.php

<?php

use Illuminate\Support\Facades\Route;

/*
|--------------------------------------------------------------------------
| Web Routes
|--------------------------------------------------------------------------
|
| Here is where you can register web routes for your application. These
| routes are loaded by the RouteServiceProvider within a group which
| contains the "web" middleware group. Now create something great!
|
*/

Route::get('/', function () {
    return view('welcome');
});

Route::get('/dashboard', function () {
    return view('dashboard');
})->middleware(['auth'])->name('dashboard');

// ルート sayhi を追加
Route::get('/sayhi', function () {
    return sprintf('<h1>Hi, %s</h1>', auth()->user()->name);
})->middleware(['auth'])->name('sayhi');

require __DIR__.'/auth.php';

未ログインの状態でsayhiページを開いてみましょう。php artisan serveでwebサーバを起動しているならhttp://localhost:8000/sayhiから開けます。アクセスがガードされログインページに飛ばされるはずです。そしてログインすると。。。

sayhiページが表示されました。

redirect()->intended(...)、再び

認証が必要なページにアクセスしログインページに飛ばされた場合、ログイン後は元々アクセスしようとしていたページにリダイレクトされるようです。これはどういうプロセスでそうなっているのでしょうか？

以下、AuthenticatedSessionControllerのstore()を再掲します。

app/Http/Controllers/AuthenticatedSessionController.php

/**
 * Handle an incoming authentication request.
 *
 * @param  \App\Http\Requests\Auth\LoginRequest  $request
 * @return \Illuminate\Http\RedirectResponse
 */
public function store(LoginRequest $request)
{
    $request->authenticate();
 
    $request->session()->regenerate();
 
    return redirect()->intended(RouteServiceProvider::HOME);
}

前回は掘り下げなかった、redirect()->intended(…) の処理を追ってみましょう。 intended()は以下のように定義されています。

vendor/laravel/framework/src/Illuminate/Routing/Redirector.php

/**
 * Create a new redirect response to the previously intended location.
 *
 * @param  string  $default
 * @param  int  $status
 * @param  array  $headers
 * @param  bool|null  $secure
 * @return \Illuminate\Http\RedirectResponse
 */
public function intended($default = '/', $status = 302, $headers = [], $secure = null)
{
    $path = $this->session->pull('url.intended', $default);

    return $this->to($path, $status, $headers, $secure);
}

ここでの処理のポイントは３つです。

sessionにurl.intendedがセットされていればその値をリダイレクト先とする
url.intendedがセットされていなければ、引数で渡されたパスをリダイレクト先とする（ここではRouteServiceProvider::HOME）
url.intendedも引数もセットされていない場合、引数のデフォルト値である'/'をリダイレクト先とする

ログインページに飛ばされた際、debugbarのsessionタブを開くとurl.intendedに元々アクセスしようとしていたURLがセットされているのが確認できます。

尚、sessionのpull()はセッションから値を取得し削除する為、ログイン後url.intendedはセッションに残っていません。

ログイン後のリダイレクト先、その１

Mon, 02 May 2022 07:55:30 +0900

ECサイトなど会員登録機能を備えたサイトは大きくなると利便性やマーケティング的な観点からページ遷移にとても気を使うようになります。ログイン後のリダイレクト先も重視される導線の一つですね。先の案件でそれらを見直す機会があったので挙動や設定方法について備忘録を兼ねてまとめます。

事前準備

以降の解説はLaravel Breezeがインストールされている状態から進めます。一緒に手を動かしながら進める方は過去の記事、Laravel 8.xのインストールを参考にインストールして下さい。

途中、debugbarでsessionの状態を確認します。必要であればそちらもインストールを、

composer require barryvdh/laravel-debugbar --dev

ログインボタンからログインした際のリダイレクト先

まずは通常のログイン遷移を確認してみましょう。新規のプロジェクトにLaravel Breezeをインストールした状態だと、トップページ右上のLog inからログインからログインできますね。

そして、ログイン後はdashboardページへ遷移しました。

これを任意のURL、例えば、トップページ（’/’）に変更したい場合はどうすれば良いでしょうか？

ログイン時に実行されているのはAuthenticatedSessionControllerのstore()ですので、そちらを確認してみましょう。

app/Http/Controllers/AuthenticatedSessionController.php

/**
 * Handle an incoming authentication request.
 *
 * @param  \App\Http\Requests\Auth\LoginRequest  $request
 * @return \Illuminate\Http\RedirectResponse
 */
public function store(LoginRequest $request)
{
    $request->authenticate();

    $request->session()->regenerate();

    return redirect()->intended(RouteServiceProvider::HOME);
}

リダイレクト先は、redirect()->intended(RouteServiceProvider::HOME);によって決まっているようです。こちらのメソッドの詳しい解析は後に回して、引数のRouteserviceProvider::HOMEという定数に注目です。

RouteServiceProviderを確認するとHOMEは現在のリダイレクト先である’/dashboard’となっていました。この値をトップページ（’/’）に変更してみましょう。

app/Providers/RouteServiceProvider.php

class RouteServiceProvider extends ServiceProvider
{
    /**
     * The path to the "home" route for your application.
     *
     * This is used by Laravel authentication to redirect users after login.
     *
     * @var string
     */
    public const HOME = '/';    // '/dashboard' から変更
...

一旦ログアウトしてから再ログインすると、今度はトップページ（’/’）にリダイレクトされましたね。続きます。

Laravel 9.xのインストール

Thu, 17 Feb 2022 08:44:12 +0900

L6以来のLTSという事で待望の(?)Laravel9がリリースされました。という事で早速installを試してみます。

バージョン

まずはサポートの予定をチェックしてみましょう。

おや？Laravel9のLTS表記が消えていますね。なぜでしょう？ Taylor OtwellさんがTwitterで説明していました。

L9はPHP8.0以上をシステム要件としていましたが、依存パッケージである Symfony6.1 がPHP8.1を要件とする可能性があり（2022/02/16現在 github上で協議中）、L9のサポート期限はその決定次第で決まるとの事です。表の期限は最悪のシナリオを想定したもので、symfonyの最低要件がPHP8.1になった場合でも２年間はサポートされるよ、との事です。

~~こちらの情報はモニターしておく必要がありそうです。~~

※追記@2022-02-28

Symfony6.1はPHP8.1以上が必須となりました、という事でL9のサポートは２年間となりました。また、これに合わせて次のL10ではPHP8.1以上が要件となりした。

新規プロジェクト

前項でも触れましたがL9はPHP8.0以上が必要です、まだの方は先にPHPをバージョンアップして下さい。以下のコマンドでL9xというプロジェクトを作成してみましょう。

composer create-project --prefer-dist laravel/laravel:^9.0 l9x

プロジェクトディレクトリに移動し、早速立ち上げてみましょう。

cd L9x
php artisan serve

ブラウザでhttp://127.0.0.1:8000にアクセスするとお馴染みのホーム画面が表示されました。

route:list

今回のアップデートで変わった内容の１つにroute:listが刷新された、とありました。早速試してみましょう。

php artisan route:list

以下のようなカラフルな出力になりました。

L8では以下のようなテーブル出力でした。

刷新されたエラーページ

エラーページの出力も刷新され、パッケージがfacade/ignitionからspatie/laravel-ignitionに変更されました。

試しに表示してみましょう。ルートページにアクセスした際にエラーが発生するように変更します。

routes/web.php

...
Route::get('/', function () {
    throw new \Exception('Error on purpose');    // 追加
    return view('welcome');
});

ブラウザでhttp://127.0.0.1:8000にアクセスするとエラーページが表示されました。ダークモードですね。

リクエストの詳細情報などはページ下部にあります。メニューバーのCONTEXTからも飛べます。見やすいし、コピペしやすそうですね。

右上の歯車マークから、使用しているEDITORを指定する事で、エラー画面からエディタを開き該当行にジャンプできます。 facade/ignitionにも同様の機能がありましたが、デフォルトのエディタにPHPStormが指定されており、私が使用しているVS Codeに変更する場合は.envに設定を書かなければならなかったので大変便利です。

該当行のペンマークのアイコンをクリックしてエディタ上でコードの該当部分にジャンプ。

エラー調査が捗りそうです。

ddd()復活？

過去の記事で紹介したddd()ですが、L9で使うとCall to undefined function ddd()エラーが発生してしまいます。

その件について、こちらのGitHubのDiscussionでDiscussされています。

spatie/laravel-ignitionの開発メンバー側はddd()を使ってないのでパッケージをシンプルにする為に削除したとの事。

しかし、戻して欲しい、という意見が多かったので近い内に追加されるそうです。コミュニティの意見をしっかりと聞いて反映する良いパッケージだな、という印象を受けました。