Eloquent on ララジャパン

第２のデータベースにアクセス

Fri, 14 Nov 2025 12:04:49 +0900

たいていのプロジェクトで扱うデータベースは１つですが、これが２つあるいは３つのデータベースにアクセスするとなったら、どう対応するのでしょう？というのが今回のテーマです。

データベースのコネクション

まず、データベースのコネクションに関しての説明です。扱うデータベースが１つとすると、

.env

...
DB_CONNECTION=mysql
DB_HOST=localhost
DB_PORT=3306
DB_DATABASE=db1
DB_USERNAME=root
DB_PASSWORD=password
...

と設定します。これらの環境変数は、以下のconfig/database.phpにおいてのデータベース接続のための値となります。

config/database.php

return [

    'default' => env('DB_CONNECTION', 'mysql'),

    'connections' => [

        'mysql' => [
            'driver' => 'mysql',
            'url' => env('DB_URL'),
            'host' => env('DB_HOST', '127.0.0.1'),
            'port' => env('DB_PORT', '3306'),
            'database' => env('DB_DATABASE', 'laravel'),
            'username' => env('DB_USERNAME', 'root'),
            'password' => env('DB_PASSWORD', ''),
            'unix_socket' => env('DB_SOCKET', ''),
            'charset' => env('DB_CHARSET', 'utf8mb4'),
            'collation' => env('DB_COLLATION', 'utf8mb4_unicode_ci'),
            'prefix' => '',
            'prefix_indexes' => true,
            'strict' => true,
            'engine' => null,
            'options' => extension_loaded('pdo_mysql') ? array_filter([
                PDO::MYSQL_ATTR_SSL_CA => env('MYSQL_ATTR_SSL_CA'),
            ]) : [],
        ],
...

扱うデータベースが２つのとき

デフォルトのデータベースへのコネクションが、mysqlとすると、もう１つ扱うデータベースを mysql2 として、先のconfig/database.phpに追加することができます。

config/database.php

return [

    'default' => env('DB_CONNECTION', 'mysql'),

    'connections' => [
      　 // デフォルトのデータベース
        'mysql' => [
        ...
        ],

　　　　// 第２のデータベース
        'mysql2' => [
            'driver' => 'mysql',
            'url' => env('DB2_URL'),
            'host' => env('DB2_HOST', '127.0.0.1'),
            'port' => env('DB2_PORT', '3306'),
            'database' => env('DB2_DATABASE', 'laravel'),
            'username' => env('DB2_USERNAME', 'root'),
            'password' => env('DB2_PASSWORD', ''),
            'unix_socket' => env('DB2_SOCKET', ''),
            'charset' => env('DB2_CHARSET', 'utf8mb4'),
            'collation' => env('DB2_COLLATION', 'utf8mb4_unicode_ci'),
            'prefix' => '',
            'prefix_indexes' => true,
            'strict' => true,
            'engine' => null,
            'options' => extension_loaded('pdo_mysql') ? array_filter([
                PDO::MYSQL_ATTR_SSL_CA => env('MYSQL_ATTR_SSL_CA'),
            ]) : [],
        ],
...

mysql2では、環境関数名は皆DB2_のプレフィックスとなっていることに注意を。

.envでは、こんな感じに設定します。

.env

...
DB_CONNECTION=mysql
DB_HOST=localhost
DB_PORT=3306
DB_DATABASE=db1
DB_USERNAME=root
DB_PASSWORD=password

DB2_HOST=localhost
DB2_PORT=3307
DB2_DATABASE=db2
DB2_USERNAME=root2
DB2_PASSWORD=password2
...

第２のデータベースにアクセスするには

さて、第２のデータベースにアクセスしてみましょう。

クエリビルダーでは、以下のようにconnection()の引数に第２のデータベースのコネクション mysql2 を指定するだけです。

DB::connection('mysql2')->table('user')->get();

Eloquentではどうでしょう。

まず、第２のデータベースのモデルを作成します。

namespace App\Models;

use Illuminate\Database\Eloquent\Model;

class RemoteUser extends Model
{
    protected $table = 'users';

    protected $connection = 'mysql2'; // ここでコネクションを指定
}

ここでは、デフォルトのデータベースと同じように、第２のデータベースでも users というテーブルが存在すると仮定します。通常と違って、mysql2のコネクションが指定されていることも注意を。

この設定なら、クエリの実行はデフォルトのデータベースのEloquetとまったく変わりません。簡単ですね。

RemoteUser::all();

Eloquentで動的にコネクションを指定

先のEloquentはモデル内ですでに指定されている固定のコネクションでしたが、前もってわからないときはどうしましょう。つまりモデルの定義が以下のようなときのことです。

namespace App\Models;

use Illuminate\Database\Eloquent\Model;

class RemoteUser extends Model
{
    protected $table = 'users';
}

このようなときは、クエリ実行時において、以下のようにコネクションを指定します。

RemoteUser::on('mysql2')->get();

上では、RemoteUser::on(‘mysql2’)は、Illuminate\Database\Eloquent\Builderを返すので、RemoteUser::on(‘mysql2’)::all()とは出来ないことに注意を。

混乱してはいけないLaravelの動的プロパティ - Eloquent編

Fri, 19 Apr 2024 05:45:38 +0900

LaravelではModelやCollectionやRequestなどのクラスにおいて動的プロパティがコードの短縮形としてよく使われます。しかし、同じクラスでメソッドとして定義したものがいきなりプロパティとして使われるので、私は昔よく混乱したものです。今回はまずEloquent編として代表的な動的プロパティの活用を混乱しないように説明します。

Eloquentのアクセッサー

まず、動的プロパティの例として、DBには対応する項目は存在しないのに、あたかも存在する項目のように振る舞うEloquentのアクセッサーです（ミューテーターも同じですが）。

DBのテーブルにfirst_name（名前）とlast_name（苗字）が存在するとして、姓名（full_name）を返すアクセッサーメソッドを定義します。

namespace App\Models;
 
use Illuminate\Database\Eloquent\Casts\Attribute;
use Illuminate\Database\Eloquent\Model;
 
class User extends Model
{
...
    /**
     * 姓名を返すアクセッサー
     *
     * @return \Illuminate\Database\Eloquent\Casts\Attribute
     */
    protected function fullName(): Attribute
    {
        return Attribute::make(
            get: fn ($value, $attribute) => $attribute['last_name'].' '.$attribute['first_name'],
        );
    }
}

これを使用するときは、動的プロパティとして以下のように使います。

> User::find(1);
[!] Aliasing 'User' to 'App\Models\User' for this Tinker session.
= App\Models\User {#5393
    id: 1,
    created_at: "2024-04-16 03:42:31",
    updated_at: "2024-04-16 03:42:31",
    first_name: "直子",
    last_name: "山田",
  }

> User::find(1)->full_name;
= "山田 直子"

先ほどのアクセッサーのメソッドfullName()をコールして姓名full_nameを動的プロパティとして返します。

ちなみに、fullName()のメソッドはprotectedで宣言されているので直接はコールできません。

> User::find(1)->fullName();
   BadMethodCallException  Call to undefined method App\Models\User::fullName().

EloquentのRelationship

今度は、EloquentのRelationshipの動的プロパティです

典型的なブログを例として、ユーザーとブログの投稿を使います。それぞれのDBテーブルを代表してUserとPostがModelのクラスとなります。そして、Userのクラスでは、それらの１対多の関係を以下のように定義します。

namespace App\Models;
 
use Illuminate\Database\Eloquent\Model;
 
class User extends Model
{
    /**
     * ユーザー１に対して複数のブログの投稿
     */
    public function posts()
    {
        return $this->hasMany(Post::class);
    }
}

この関係を利用して、特定のユーザーのブログのレコードを取得するのは通常以下のようになります。

$user = User::find(1);
$posts = $user->posts()->get(); // Collectionを返す

しかし、動的プロパティを使うと、

$posts = $user->posts;

と短縮形で書くことができます。先の非短縮形と同じ結果となります。便利ですね。

しかし、この短縮形、非短縮形でできることがなんでもできる訳ではありません

例えば、非短縮形のメソッド方式では、

$user->posts()->orderBy('created_at')->get();

とレコードをソートできますが、短縮形の動的プロパティの使用ではエラーとなります。

$user->posts->orderBy('created_at');

BadMethodCallException  Method Illuminate\Database\Eloquent\Collection::orderBy does not exist.

これは、$user->posts()がIlluminate\Database\Eloquent\Relations\HasManyを返すのに、$user->postではIlluminate\Database\Eloquent\Collectionを返すからです。Collectionには、orderBy()というメソッドはないのです。しかし、前者にはあります。

ちなみに後者では、CollectionのメソッドsortBy()を使用すると同じ結果が得られます。

$user->posts->sortBy('created_at');

もう１つ、より混乱しそうな例を挙げてみましょう。

まずは非短縮形から、

$user->posts()->where('title', '=', 'ブログタイトル')->get();

タイトルに特定の条件で絞ったクエリーです。ちなみに、実行されたSQLは、以下となります。

select * from `post` where `user`.`id` = 1 and `user`.`id` is not null and `title` = 'ブログタイトル';

さて、これを短縮形の動的プロパティで書くと、

$user->posts->where('title', '=', 'ブログタイトル');

->get()がないだけの違いですが、これはまったく正規です。返す結果も前者と同じです。where()はCollectionのメソッドにもあるのですね。

実行されたSQLも見てみましょう。

select * from `post` where `user`.`id` = 1 and `user`.`id` is not null;

違いわかりますか？タイトルを制限するwhereの条件文がSQL文にありません。つまり、ユーザーが投稿したレコードをいったん全部取得して、Collectionのwhere()のメソッドでフィルターしているのです。

両者ともに実行結果は同じですが、どこまでがデータベースにより実行されるか、どこからがCollectionのメソッドで実行するかにおいての違いです。この違いでパフォーマンスが違ってきます。一般的には前者のようにDBにたくさん仕事をしてもらうのが効率的です。注意が必要ですね。

参照

混乱してはいけないLaravelの動的プロパティ – Collection編混乱してはいけないLaravelの動的プロパティ – 裏側編混乱してはいけないLaravelの動的プロパティ – PHP8.2で廃止となった編

【Eloquent】has() vs joinSub()

Mon, 24 Oct 2022 12:54:19 +0900

過去の記事でも紹介されていますが、親子（or 1対多）関係にあるModelにおいて、「１つ以上子を持つ親」などの条件で絞り込む際にhas()は便利です。

しかし、has()を使わずともjoinSub()でサブクエリを指定して同じ条件で絞り込む事もできそうです。どちらを使うのがベターなのか？気になったので調べてみました。

has()とjoinSub()の違い

例えば、店(Shop)と商品(Product)というModelが有った場合、「１つ以上商品を持つ店」はそれぞれ以下で絞り込むことができます。

// has()で絞り込み
$shops = Shop::has('product')->get();

// joinSub()で絞り込み
$sub = Product::distinct()->select('shop_id');

$shops = Shop::joinSub($sub, 'sub', function ($join) {
        $join->on('sub.shop_id', '=', 'shop.shop_id');
    })->get();

見ての通り、joinSub()の方が冗長ですね。

発行されたsqlはそれぞれ以下になります。

# has()のsql
select * from `shop` where exists (select * from `product` where `shop`.`shop_id` = `product`.`shop_id`);

# joinSub()のsql
select * from `shop` inner join (select distinct `shop_id` from `product`) as `sub` on `sub`.`shop_id` = `shop`.`shop_id`;

has()ではEXISTS句で相関サブクエリを使用して絞り込んでいます。

相関サブクエリとは

mysqlの公式ドキュメントからの引用です。

相関サブクエリは、外部クエリにも現れるテーブルへの参照を含むサブクエリです。

前述のhas()のsqlでは、外部クエリのFROMに指定しているshopをサブクエリ内で参照している為、相関サブクエリと言えます。

相関サブクエリの注意点

レコード数が多いテーブルに紐づいたModelにてhas()使う際は注意が必要です。

相関サブクエリでは外部クエリの結果行数分、比較処理が行われる可能性があり、結果行数が多ければ遅くなる為です。

例えば前述のhas()のsqlでは、shopのレコード数 x productのレコード数分の比較処理が走ることになります。（EXISTS句では条件にヒットする行が見つかればその時点でtrueを返し、次のレコードの比較処理に移るため、あくまでも全件ヒットしなかった場合）

とはいえ、それをjoinSub()に置き換えた場合もGROUP BYやDISTINCTで重複を削除する処理のコストが有るため、一概にどちらが速いと言い切れません。

実際に実装する環境でテストしてみるのが良いでしょう。

今回の実装環境ではhas()でもjoinSub()でも速度に大きな違いはありませんでした。であればよりシンプルに記述できるhas()がベターと考えてそちらを採用することにしました。

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",
   ]

isDirty() vs wasChanged()（更新）

Mon, 13 Jun 2022 05:46:58 +0900

３年前に書いた投稿の更新です（その投稿自体その４年前の投稿の更新です）。factoryからEloquentのインスタンスの作成も変わり、また新たな発見がありました。

まず、tinkerを使用して、isDirty()の復習です。 factory()を使って、１つレコードを作成します。

>>> User::factory()->create();
=> App\Models\User {#3632
     name: "村山 涼平",
     email: "ekoda.asuka@example.com",
     email_verified_at: "2022-06-12 20:18:11",
     #password: "$2y$10$92IXUNpkjO0rOQ5byMi.Ye4oKoEa3Ro9llC/.og/at2.uheWG/igi",
     #remember_token: "h7d19XhYd4",
     updated_at: "2022-06-12 20:18:11",
     created_at: "2022-06-12 20:18:11",
     id: 1,
   }

作成したレコードの名前を更新しますが、DBでなくオブジェクトのみの更新のために、fill()を使用します。

>>> $user = User::find(1);
=> App\Models\User {#3949
     id: 1,
     name: "村山 涼平",
     email: "ekoda.asuka@example.com",
     email_verified_at: "2022-06-12 20:18:11",
     #password: "$2y$10$92IXUNpkjO0rOQ5byMi.Ye4oKoEa3Ro9llC/.og/at2.uheWG/igi",
     #remember_token: "h7d19XhYd4",
     created_at: "2022-06-12 20:18:11",
     updated_at: "2022-06-12 20:18:11",
   }
>>> $user->fill(['name' => '山田太郎']);
=> App\Models\User {#3949
     id: 1,
     name: "山田太郎",
     email: "ekoda.asuka@example.com",
     email_verified_at: "2022-06-12 20:18:11",
     #password: "$2y$10$92IXUNpkjO0rOQ5byMi.Ye4oKoEa3Ro9llC/.og/at2.uheWG/igi",
     #remember_token: "h7d19XhYd4",
     created_at: "2022-06-12 20:18:11",
     updated_at: "2022-06-12 20:18:11",
   }

nameが変わりましたね。実際、オブジェクトが更新したかどうかは、isDirty()を使います。

>>> $user->isDirty();
=> true

変更していますね。項目ごとはどうでしょう？

>>> $user->isDirty('name');
=> true
>>> $user->isDirty('email');
=> false

nameの変更がありますが、emailの変更はなしです。正しいです。

ここで、変更したオブジェクトをもとに対応するレコードをDBに保存します。

>>> $user->save();
=> true

さて、この時点でのisDirty()の返り値は？

>>> $user->isDirty();
=> false
>>> $user->isDirty('name');
=> false

もう、isDirty()では、変更があったかどうかの判断はできません、何もDirtyではありません。

この時点、つまりオブジェクトの更新をDBに反映した時点でレコードが更新したかどうかを判断するには、isDirty()ではなく、wasChanged()を使用します。

>>> $user->wasChanged();
=> true
>>> $user->wasChanged('name');
=> true
>>> $user->wasChanged('email');
=> false

save()前のisDirty()の結果とまったく同じです。

実際には、こんなコードでwasChanged()は使われます。

...
$user->fill(['name' => '山田太郎']);

if ($user->isDirty()) {
    $user->save();
    if ($user->wasChagned('name')) {
        //nameが更新されたときのみ、以下のコードを実行
        ...
    }
}
...

さてさて、上の話は既存にあるレコードを更新したときの話です。新規のレコード作成のときもチェックしてみます。

>>> $user = User::factory()->make();
=> App\Models\User {#4588
     name: "浜田 京助",
     email: "tsubasa.saito@example.org",
     email_verified_at: "2022-06-12 20:21:59",
     #password: "$2y$10$92IXUNpkjO0rOQ5byMi.Ye4oKoEa3Ro9llC/.og/at2.uheWG/igi",
     #remember_token: "ZzZh0fHqJA",
   }

先ほどと違うのは、create()の代わりにmake()が使用されているところです。create()と違ってまだDBレコードは作成されていません。この時点では、

>>> $user->isDirty();
=> true

更新と同じですね。 DBにレコードを保存してみます。

>>> $user->save();
=> true

さて、この時点でのisDirty()の返り値は？

>>> $user->isDirty();
=> false

期待通りです。しかし、

>>> $user->wasChanged();
=> false

こちらは、更新時と違ってtrueとはなりません。wasChangedは訳せば更新したかという意味であり、作成されたかではないとすればfalseになるのは正しいのでしょう。

しかし、$userのようなインスタンスが既存のレコードを更新したのか、新規に作成されたのかが前もってわからないときの判断としてwasChanged()を使用できません。とかいってwasCreated()というメソッドもないのです。滅多に直面するケースは少ないですが、注意しましょう。

whereInが返す順番

Mon, 23 May 2022 04:08:20 +0900

whereIn()はLaravelではEloquentやQuery Builderで良く使われます。特にwith()メソッドでは自動的に。今までこのクエリが返すレコードの順番はたいして気にしていなかったのですが、これはどうしたものか、という状況にぶち当たりました。

SQLというのは何も指定しない、つまりorderByを指定しないとSQLが返すレコードの順番は保証がありません。以下見てください。

>>> User::whereIn('id', [10,1,3])->pluck('id');

=> Illuminate\Support\Collection {#4581
     all: [
       1,
       3,
       10,
     ],
   }

直感的には、10,1,3を返すと思うところ、なぜかその順番にソートされていません。自動的にid順となっています。多分、idがDBテーブルusersのプライマリーキーだから、その順で返している？

とにかく、orderByを明確に指定していないので返す順を頼りにすることはできません。

しかし、状況によっては指定した順番で返す必要あります。以下のように、お客さんが閲覧した商品の順番、最新閲覧した商品を一番左に持ってきます。

例えば、この商品のidがクッキーにその表示順でidを保存した場合は、その表示順で商品名や価格をDBから取得してくる必要あります。

この場合は、一般的はDBの項目の値に基づくorderByは使えません（もちろん、閲覧日時とかを別のDBテーブルに保存していないという仮定で）。

さて、どうしましょう？とリサーチすると便利なSQL関数がありました。こんな感じで使います。

>>> User::whereIn('id', [10,1,3])->orderByRaw("FIELD(id,10,1,3)")->pluck('id');

=> Illuminate\Support\Collection {#4579
     all: [
       10,
       1,
       3,
     ],
   }

そして、これを先の商品の例に適応すると、こんな感じです。$productIdsには配列として、例えば[10,1,3]のような値があると仮定します。

Product::query()
    ->whereIn('product_id', $productIds)
    ->orderByRaw('FIELD(product_id, '.implode(',', $productIds).')')
    ->pluck('name', 'product_id');

古いレコードをプルーンします

Sat, 19 Mar 2022 12:14:36 +0900

古くなってもう要らないDBレコードを削除することを、プルーン(prune)あるいはパージ(purge)などと言います。カスタムのArtisanのコマンドを書いて処理してもいいのだけれど、LaravelではこれがModelの中であるトレイトを使うだけで、組織的できてしまいます。

プルーンの対象は特定のDBモデルのレコードです。ここでは、会員ログインのレコードを貯めているuser_logsのテーブルのモデルUserLogを例とします。以下のようにPrunableのトレイトを追加して、削除したい対象のクエリーの条件をprunable()で定義するだけです。

app/Models/UserLog.php

namespace App\Models;
 
use Illuminate\Database\Eloquent\Model;
use Illuminate\Database\Eloquent\Prunable;
 
class UserLog extends Model
{
    use HasFactory;
    use Prunable;

    const UPDATED_AT = null; // updated_atの項目はない
 
    /**
     * Get the prunable model query.
     *
     * @return \Illuminate\Database\Eloquent\Builder
     */
    public function prunable()
    {
        return static::where('created_at', '<=', now()->subYear()); // １年以上昔のレコードが対象
    }
}

そして、以下のコマンドの実行をクロンに設定にします。

$ php artisan model::prune

簡単でしょう。

削除する前に以下のように実際の削除なしの予行も可能です。

$ php artisan model:prune --pretend
8 [App\Models\UserLog] records will be pruned.

８個のレコードが削除されるよ、と知らせてくれます

tinkerで実際にプルーンを実行してみましょう。どのようなSQL文が実行されるか興味あります。

>>> Artisan::call('model:prune');
=> 0
>>> sql();
=> [
     [
       "query" => "select count(*) as aggregate from `user_logs` where `created_at` <= ?",
       "bindings" => [
         Illuminate\Support\Carbon @1616039564 {#3572
           date: 2021-03-18 03:52:44.536379 UTC (+00:00),
         },
       ],
       "time" => 4.94,
     ],
     [
       "query" => "select * from `user_logs` where `created_at` <= ? order by `id` asc limit 1000",
       "bindings" => [
         Illuminate\Support\Carbon @1616039586 {#3546
           date: 2021-03-18 03:53:06.837232 UTC (+00:00),
         },
       ],
       "time" => 1.36,
     ],
     [
       "query" => "delete from `user_logs` where `id` = ?",
       "bindings" => [
         1,
       ],
       "time" => 7.25,
     ],
     [
       "query" => "delete from `user_logs` where `id` = ?",
       "bindings" => [
         2,
       ],
       "time" => 3.11,
     ],
...

なるほど、１個１個レコードは削除されるのですね。これは、モデルのdeletingやdeletedのイベント処理を可能にするためです。

そのイベント処理が必要でないなら、一括実行も可能です。トレイトをPrunableからMassPrunableにするだけです。

app/Models/UserLog.php

namespace App\Models;
 
use Illuminate\Database\Eloquent\Model;
use Illuminate\Database\Eloquent\MassPrunable;
 
class UserLog extends Model
{
    use HasFactory;
    use MassPrunable;

    const UPDATED_AT = null;
 
    /**
     * Get the prunable model query.
     *
     * @return \Illuminate\Database\Eloquent\Builder
     */
    public function prunable()
    {
        return static::where('created_at', '<=', now()->subYear()); // １年以上昔のレコードが対象
    }
}

再度、tinkerでSQL文をチェックすると、

>>> Artisan::call('model:prune');
=> 0
>>> sql();
=> [
     [
       "query" => "delete from `user_logs` where `created_at` <= ? limit 1000",
       "bindings" => [
         Illuminate\Support\Carbon @1616039978 {#3567
           date: 2021-03-18 03:59:38.916448 UTC (+00:00),
         },
       ],
       "time" => 5.61,
     ],
   ]
>>>

削除のSQL文１つだけになっていました。いたれりつくせりです。

検索結果をページネーション

Mon, 07 Mar 2022 07:04:03 +0900

「ページネーションのデータを変える」の続きです。検索画面を用意して検索結果をページネーションします。

検索画面のページネーション

まず、こんな検索画面を作りたいです。

検索項目に値を入れると、値により絞り込まれた検索結果が表示されます。ごく普通の検索画面です。画面の右下にはページネーションも表示されます。ここでは１画面に２レコードだけ表示です。

routeの定義は、GETだけで十分です。そう、検索条件はすべてURLに入れます。

routes/web.php

...
Route::get('/search', [SearchController::class, 'index'])->name('search');
..

コントローラの作成も簡単です。あまりにも短いのでカットせずにすべて見せてしまいます。

app/Controllers/SearchController.php

namespace App\Http\Controllers;

use App\Models\User;
use Illuminate\Http\Request;

class SearchController extends Controller
{
    public function index(Request $request)
    {
        $query = User::query();

        if ($value = $request->name) {
            $query->where('name', 'like', "%{$value}%");
        }

        if ($value = $request->email) {
            $query->where('email', 'like', "%{$value}%");
        }

        $users = $query->paginate(2);

        return view('user.search', compact('users'));
    }
}

しかし、このコード大いに問題ありです。先の画面でページネーションの２ページをクリックすると、

検索結果３件だったのに１０件になっているし、ページネーションも２ページから５ページに。２ページ目なら表示するのは１件のみでは。おかしいところだらけです。一番の問題はGETだから、ブラウザのURLには入力した値が追加されるのに、?page=2だけです。

この問題の解決はとても簡単です。

上のコントローラのコードで、withQueryString()を以下のように追加するだけなのです。

app/Controllers/SearchController.php

...
    public function index(Request $request)
    {
        $query = User::query();

        if ($value = $request->name) {
            $query->where('name', 'like', "%{$value}%");
        }

        if ($value = $request->email) {
            $query->where('email', 'like', "%{$value}%");
        }

        $users = $query->paginate(2)->withQueryString(); //ここに追加

        return view('user.search', compact('users'));
    }
...

修正した２ページ目の画面です。

URLに?email=example.com&page=2とクエリーの文字列が入っていますね。

クエリーをリファクター

上のコントローラのコードでは条件文のifを使い検索のクエリーを作成しています。それ自体は問題は何もありません。すでに十分わかりやすいです。しかし、Laravel風にすると以下のようにも書くことができます。

app/Controllers/SearchController.php

...
class SearchController extends Controller
{
    public function index(Request $request)
    {
        $query = User::query()
            ->when($request->name, function($query, $value) {
                    return $query->where('name', 'like', "%{$value}%");
            })
            ->when($request->email, function($query, $value) {
                return $query->where('email', 'like', "%{$value}%");
            });

        $users = $query->paginate(2)->withQueryString();

        return view('user.search', compact('users', 'request'));
    }
}
...

whereでなくwhenの関数となっているところに注意してください。最初の引数の値が存在するなら次で定義する匿名関数を実行です。

存在を知らなかったchunkById()

Sun, 30 Jan 2022 12:45:32 +0900

以前にEloquentの出力のチャンキングを紹介しました。処理中のメモリーの使用量を減らすためのチャンキングですが、実行速度が遅いということでそれを改善する対策もこしらえました。３年前以上のことです。しかし、そのためのメソッドがすでにEloquentのメソッドに存在することに最近気づきました。

まず、以前のポストのリンクを再掲載（読んでね）。チャンキングで使用メモリを抑えるチャンキングは遅い

後者の「チャンキングは遅い」での対策は、対象のテーブルのプライマリIDを指定してクエリーを実行して、チャンキングの速度の改善を図りました。ここで再掲載します。

...
        $max = User::max('id');
        $unit = 1000;

        for ($i = 0; $i < intval(ceil($max/$unit)); $i++) {
            $from = $i * $unit + 1;
            $to = ($i + 1) * $unit;

            $rows = User::where('id', '>=', $from)
                ->where('id', '<=', $to)
                ->get();

            foreach ($rows as $row) {
                $values = [
                    $row->id,
                    $row->created_at,
                    $row->name,
                    $row->email
                ];
 
                fputcsv($fh, $values);
           }
       }
...

単にループしているだけで、毎回毎回これをコードするのはちょっと面倒ですね。

ところが、最近、新人のプログラマーが書いたコードをレビューしていたら、

...
User::chunkById(1000, function($rows) use($fh) {
    foreach ($rows as $row) {
        $values = [
            $row->id,
            $row->created_at,
            $row->name,
            $row->email
        ];
 
        fputcsv($fh, $values);
    }
});
...

chunkById()というメソッドを使いすっきりしたコードになっているではないですか。

そんなメソッドあったかなあと思いつつ、tinkerを使って実行されたsql文を見てみると、

>>> User::chunkbyId(1000, function($rows) {})
=> true

>>> sql()
=> [
     [
       "query" => "select * from `users` order by `id` asc limit 1000",
       "bindings" => [],
       "time" => 3.86,
     ],
     [
       "query" => "select * from `users` where `id` > ? order by `id` asc limit 1000",
       "bindings" => [
         1000,
       ],
       "time" => 2.03,
     ],
     [
       "query" => "select * from `users` where `id` > ? order by `id` asc limit 1000",
       "bindings" => [
         2000,
       ],
       "time" => 1.85,
     ],
...

私の解決策では上限と下限のidを指定してレコードを取得しているところ、chunkId()では、idで並べ替えして、開始のidを指定してそこからチャンクの数（ここでは、1000）を指定しています。なるほど。実行速度も測定したところ私の解決策と同様にchunk()に比べて確実に速い。

さて、この便利もののchunkById()ですが、ひとつ注意が必要です。

例えば、以下のように２つのテーブルをjoinしてchunkById()を適用するとき、

>>> Shop::join('product', 'shop.shop_id', '=', 'product.shop_id')
　　->chunkbyId(1000, function($row) { /* nothing */ });

Illuminate\Database\QueryException with message 'SQLSTATE[23000]: Integrity constraint violation: 1052 Column 'shop_id' in where clause is ambiguous (SQL: select `shop`.`shop_id`, `product`.`product_id` from `shop` inner join `product` on `shop`.`shop_id` = `product`.`shop_id` where `shop_id` > 1913 order by `shop_id` asc limit 1000)'

shop_idが曖昧というエラーになってしまいます。

使用されている、sql文を見ると、

>>> sql()
=> [
     [
       "query" => "select `shop`.`shop_id`, `product`.`product_id` from `shop` inner join `product` on `shop`.`shop_id` = `product`.`shop_id` order by `shop_id` asc limit 1000",
       "bindings" => [],
       "time" => 5.26,
     ],
   ]

order By shop_idのshop_idがshopのテーブルの項目か、productのテーブルの項目かわらかないのです。

これを解決するには、

>>> Shop::join('product', 'shop.shop_id', '=', 'product.shop_id')
    ->chunkbyId(1000, function($row) { /* nothing */ }, 'shop.shop_id', 'shop_id');

chunkById()の第３番目の引数に、明確に使用する項目名(shop.shop_id)を、第４番目にそれに取り替わる元の項目名(shop_id)を指定する必要があります。

実行するsql文は以下のようになり、エラーがなくなります。

>>> sql()
=> [
     [
       "query" => "select * from `shop` inner join `product` on `shop`.`shop_id` = `product`.`shop_id` order by `shop`.`shop_id` asc limit 1000",
       "bindings" => [],
       "time" => 27.81,
     ],
     [
       "query" => "select * from `shop` inner join `product` on `shop`.`shop_id` = `product`.`shop_id` where `shop`.`shop_id` > ? order by `shop`.`shop_id` asc limit 1000",
       "bindings" => [
         1913,
       ],
       "time" => 22.15,
     ],
...

アクセサを無視して値を取得する

Sat, 13 Nov 2021 22:46:26 +0900

DBから取得した値を自動で加工してくれる便利な機能のアクセサですが、時としてアクセサを無視してDBから取得した素の値が欲しいケースがあります。そんな時に使える方法を３つ紹介します。

どういうケース？

例えば、公式ドキュメントの「アクセサの定義」には例として以下のコードが紹介されています。

<?php

namespace App;

use Illuminate\Database\Eloquent\Model;

class User extends Model
{
    /**
     * ユーザーのファーストネームを取得
     *
     * @param  string  $value
     * @return string
     */
    public function getFirstNameAttribute($value)
    {
        return ucfirst($value);
    }
}

そして、定義したアクセサにより名前の出力は頭文字が大文字となります。

$user->first_name;    // DBに保存されている素の値は"hikaru"
>> "Hikaru"

今回はこのようにアクセサを定義したものの、例外的にDBに保存されている素の値である"hikaru"が欲しくなった、という時に使える方法の解説です。

1. $attributes

まず１つ目に、アクセサを定義したクラス内で使える方法です。DBから取得した素の値は$attributesというprotectedプロパティに格納されているため、Modelクラス内からアクセス可能です。例えば前項のUserクラスにgetPlainFirstName()を追加してみましょう。

<?php

namespace App;

use Illuminate\Database\Eloquent\Model;

class User extends Model
{
    /**
     * ユーザーのファーストネームを取得
     *
     * @param  string  $value
     * @return string
     */
    public function getFirstNameAttribute($value)
    {
        return ucfirst($value);
    }

    public function getPlainFirstName()
    {
        return $this->attributes['first_name'];
    }
}

メソッドを呼び出すと素の値が取得できます。

$user->getPlainFirstName();
>> "hikaru"

因みに、$attributesはvendor/laravel/framework/src/Illuminate/Database/Eloquent/Concerns/HasAttributes.phpにて定義されています。

2. getRawOriginal()

続いて、Userクラス外から素の値にアクセスする方法として、getRawOriginal()が使えます。

$user->getRawOriginal('first_name');
>> "hikaru"

１点注意が必要なのは、このメソッドは$originalというプロパティから値を取得しています。$originalにはDBから取得した時点の値を保持する配列が格納されており、getDirty()などで変更が加わった項目を判別する際などに使われています。

つまり、DBから取得した後に変更した値は取得できません。

$user->first_name = 'kenji';    // 名前を"hikaru"から"kenji"に変更
$user->getRawOriginal('first_name');    // $originalから値を取得するので"hikaru"のまま
>> "hikaru"

こちらのメソッドもHasAttributes.phpに定義されているのでソースを確認してみてください。

3. getAttributes()

最後に紹介するgetAttributes()は$attributesを返すメソッドです。Userクラス外からアクセスでき、DBから取得した後に値を変更しても変更後の値が取得できます。getRawOriginal()とは異なり引数でキーを指定できない（$attributesそのものを返す）為、取得後に項目を指定する必要があります。

$user->getAttributes()['first_name'];
>> "hikaru"

$user->first_name = "kenji";
$user->getAttributes()['first_name'];    // 変更後の値が取得できる
>> "kenji"

まとめ

以上、アクセサを無視してDBから取得した素の値を取得する方法３つの紹介でした。紹介しておいてなのですが、アクセサを無視しなければならない箇所がいくつもある場合は今回紹介した方法で置き換えるよりも、本当にそのアクセサが必要なのか？見直す方が良いかと思います。

bulk insertをtransaction処理にする

Sat, 19 Jun 2021 03:00:16 +0900

以前投稿したbulk insertで大量のデータをDBに登録するの記事では10万レコードの挿入をbulk insertで行い、通常のinsertと比べてどれだけ速くなるのか検証しました。結果は一目瞭然で、大量のレコードをDBに登録する際には強力な武器になる事が分かりました。

しかし、前回のコードを実際の運用で使うには１つ問題があります。それはbulk insertの途中でエラーが発生した場合、DBに中途半端にレコードが残ってしまうという問題です。今回はこの問題を解決するために、前回のコードをtransactionに入れ、エラーが発生した際にロールバックされるように改修します。そして、transaction処理にする事でパフォーマンスにどのような影響があるか検証してみます。

エラー発生時の挙動

改修を始める前にまずは途中でエラーが発生し処理が異常終了してしまった場合の挙動を確認してみましょう。前回の記事で作成したUsersSeederを以下のように編集し、9999件目のレコード挿入でわざと重複エラーを発生させてみましょう。

database/seeds/UsersSeeder.php

use App\User;
use Faker\Factory as Faker;
use Illuminate\Database\Seeder;

class UsersSeeder extends Seeder
{
    /**
     * Run the database seeds.
     *
     * @return void
     */
    public function run()
    {
        $faker = Faker::create('ja_JP');

        $params = [];

        for ($i=0; $i < 100000; $i++) {
            $email = "test{$i}@example.com"; 

            // 9999件目でemailが重複
            if ($i == 9999) {
                $email = "test1@example.com";
            }

            $params[] = [ 
                'name' => $faker->name(),
                'email' => $email,
                'password' => 'testtest',
            ];

            if (count($params) >= 1000) {
                User::insert($params);
                $params = [];
            }
        }
    }
}

seederを実行すると以下のように重複エラーが発生するはずです。

% php artisan db:seed
Seeding: UsersSeeder

   Illuminate\Database\QueryException  : SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry 'test1@example.com' for key 'users_email_unique' (SQL: insert into `users` (`email`, `name`, `password`) values ...

この時点でDB上のレコード件数を確認してみると。。。

mysql> select count(*) from users;
+----------+
| count(*) |
+----------+
|     9000 |
+----------+
1 row in set (0.01 sec)

9999件目でエラーが発生し、処理がabortされたので最後の999件は登録されませんでしたが、それまでの9000件のレコードが登録されたままの中途半端な状態になっています。前回の記事ではseederの実行前にtruncateメソッドを実行し、テーブルを空にしていたため、再度seederを実行しても問題ありませんでした。しかし、エラーにより処理が途中で強制終了されたのであれば、失敗した中途半端な状態は残さず、実行前の状態に戻るのが望ましいです。

transaction処理の実装

それではtransaction処理を実装し、エラー発生時にロールバックするように修正してみましょう。Laravelでは以下のようにDBファサードを使うとtransaction処理が簡単に実装できます。

// transaction開始
DB::beginTransaction();

try {

    // 何かしらのDB操作...

    // transactionコミット
    DB::commit();
} catch (\Throwable $th) {

    // ロールバック
    DB::rollBack();
}

修正を加えたコードが以下になります。

database/seeds/UsersSeeder.php

use App\User;
use Faker\Factory as Faker;
use Illuminate\Database\Seeder;
use Illuminate\Support\Facades\DB;

class UsersSeeder extends Seeder
{
    /**
     * Run the database seeds.
     *
     * @return void
     */
    public function run()
    {
        DB::beginTransaction();

        try {
            $this->insertDummies();

            DB::commit();
        } catch (\Throwable $th) {
            DB::rollBack();

            throw new Exception('failed seeding User, so rolled back.');
        }
    }

    private function insertDummies()
    {
        $faker = Faker::create('ja_JP');

        $params = [];

        for ($i=0; $i < 100000; $i++) {

            $email = "test{$i}@example.com";

            // 9999件目でemailが重複
            if ($i == 9999) {
                $email = "test1@example.com";
            }

            $params[] = [
                'name'  => $faker->name(),
                'email' => $email,
                'password' => 'testtest',
            ];

            if (count($params) >= 1000) {
                User::insert($params);
                $params = [];
            }
        }
    }
}

runメソッドが冗長になってしまう為、レコード作成処理をinsertDummiesメソッドに切り出しました。レコード作成処理の途中でエラーが発生した場合はDB::rollback()によってinsertDummiesメソッド実行前に巻き戻されるはずです。

再度、seederを実行してみましょう。

% php artisan db:seed
Seeding: UsersSeeder

   Exception  : failed seeding User, so rolled back.
...

Errorが発生し期待通りロールバックされました。DB側を確認してみましょう。

mysql> select count(*) from users;
+----------+
| count(*) |
+----------+
|        0 |
+----------+
1 row in set (0.00 sec)

実行前の状態に戻されていますね。

処理速度に影響は？

通常のinsert処理からbulk insertに切り替える事の最大のメリットはその速さでしたが、transaction処理に切り替える事で何か影響は在るでしょうか？チェックしてみましょう。

insertDummiesメソッド内のエラーを発生させていた以下の行を削除し、正常終了するように直します。

database/seeds/UsersSeeder.php

...
            // 9999件目でemailが重複
            if ($i == 9999) {
                $email = "test1@example.com";
            }
...

再度、seederを実行してみましょう。

% php artisan db:seed
Seeding: UsersSeeder
Seeded:  UsersSeeder (6.87 seconds)
Database seeding completed successfully.

約6.9秒、transaction無しの状態で約5.8秒だったので約１秒遅くなりましたが、気にするほどでは無さそうですね。

bulk insertで大量のデータをDBに登録する

Mon, 03 May 2021 01:55:23 +0900

毎日走らせているcronのジョブの１つが、なかなか時間が掛かるのでどうにか改善できないかと悩んでいました。DBへデータを挿入する箇所で時間が掛かっており、コードを確認するとforループで１レコードずつinsert処理を行っていました。bulk insertするように改修したところ、劇的に処理時間が短くなりました。今回はそんな妙薬、bulk insertについてです。

Bulk insertとは？

bulk insertとはDBにレコードを保存する際に、複数のレコードを１クエリでまとめて挿入する方法です。１レコードずつクエリを発行するよりも効率的で高速です。

Laravelでは以下のようにクエリビルダのinsertメソッドを使い実装します。

DB::table('users')->insert([
    ['name' => 'John', 'email' => 'john@example.com', 'password' => 'testtest'],
    ['name' => 'Ben', 'email' => 'ben@example.com', 'password' => 'testtest'],
    ['name' => 'Tyler', 'email' => 'tyler@example.com', 'password' => 'testtest'],
]);

１レコードずつ挿入した場合とbulk insertを使った場合でどれ位処理時間が異なるのでしょうか？seederでusersテーブルに10万件のダミーレコードを登録するケースで比較してみます。

１レコードずつinsertする場合

※Laravelインストール後、DB接続設定やmigration実行完了時点の状態から進めています。

まずはseederを用意します。以下のコマンドでUsersSeederを作成してください。

php artisan make:seeder UsersSeeder

作成されたUsersSeederクラスを以下の様に編集します。

database/seeds/UsersSeeder.php

use App\User;
use Faker\Factory as Faker;
use Illuminate\Database\Seeder;
use Illuminate\Support\Facades\Hash;

class UsersSeeder extends Seeder
{
    /**
     * Run the database seeds.
     *
     * @return void
     */
    public function run()
    {
        $faker = Faker::create('ja_JP');

        for ($i=0; $i < 100000; $i++) { 
            $param = [ 
                'name' => $faker->name(),
                'email' => "test{$i}@example.com",
                'password' => 'testtest',
            ];
            User::create($param);
        }
    }
}

上記のコードではforループ内でcreateメソッドを呼んでおり、10万回ループ毎にDBにレコードが挿入されます。

emailにはループカウンターの$iが使用されています、これはusersテーブルに挿入する際にemailがユニークである必要があるためです。fakerのuniqueメソッドを使えばユニークなemailを生成することが出来ますが、10万件となると重複が発生し失敗してしまいます。

seederを追加したら以下のコマンドでcomposerのオートローダを再生成し、UsersSeederが読み込まれるようにしましょう。

$ composer dump-autoload

DatabaseSeeder.php も編集し、db:seedでUsersSeederを呼び出すようにします。コマンド実行毎にusersテーブルをtruncateメソッドで初期化し、挿入するemailが重複しないようにしています。

database/seeds/DatabaseSeeder.php

use Illuminate\Database\Seeder;
use Illuminate\Support\Facades\DB;

class DatabaseSeeder extends Seeder
{
    /**
     * Seed the application's database. 
     * 
     * @return void 
     */ 
    public function run()
    { 
        DB::table('users')->truncate();
        $this->call(UsersSeeder::class);
    }
}

これで準備が出来ました、db:seedコマンドを実行してみましょう。

$ php artisan db:seed
Seeding: UsersSeeder
Seeded: UsersSeeder (157.48 seconds)
Database seeding completed successfully.

上記はM1 MacBookAirでの実行で、約２分半掛かりました。また、Windows + VirtualBoxの仮想環境では約２０分掛かっていました。記事の内容とは関係無いですが、Appleシリコン速いですね！

bulk insertの場合

次に、UsersSeederを編集してbulk insertにしてみましょう。bulk insertにするには一度、挿入するデータを連想配列で用意し、insertメソッドに渡します。

database/seeds/UsersSeeder.php

...
public function run()
{ 
    $faker = Faker::create('ja_JP');

    $params = [];

    for ($i=0; $i < 100000; $i++) { 
        $params[] = [ 
            'name' => $faker->name(),
            'email' => "test{$i}@example.com",
            'password' => 'testtest',
        ];
    } 

    User::insert($params);
}

db:seedを実行してみましょう。

$ php artisan db:seed 
Seeding: UsersSeeder
PHP Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 4194312 bytes) in ...

流石に10万件のデータを一つの変数に格納するとメモリの使用上限に達し、エラーが発生してしまいました。（memory_limitは初期設定の128MBです）

ini_set()でmemory_limitを上げても良いですが、一体どれだけメモリを食うのか分かりません。1000件毎にinsertメソッドを実行、$paramsを初期化し、メモリ使用量を抑える事にしました。以下が修正を加えたコードです。

database/seeds/UsersSeeder.php

...
public function run()
{ 
    $faker = Faker::create('ja_JP');

    $params = [];

    for ($i=0; $i < 100000; $i++) { 
        $params[] = [ 
            'name' => $faker->name(),
            'email' => "test{$i}@example.com",
            'password' => 'testtest',
        ];

        if (count($params) >= 1000) {
            User::insert($params);
            $params = [];
        }
    } 
}

蛇足ですが、こちらの記事、High-speed inserts with MySQLにて

It takes around 1,000 inserts per query to reach the maximum throughput

と言及されているように、bulk insertの場合は１クエリ辺り1000件のインサートが最も効率が良いらしいです。

再度、db:seedを実行してみましょう。

$ php artisan db:seed
Seeding: UsersSeeder
Seeded:  UsersSeeder (5.8 seconds)
Database seeding completed successfully.

約２分半掛かっていたのが、約６秒です。約２０分掛かっていた Windows + VirtualBox の環境でも約６秒でした。すごい差です！

created_at, updated_atは自動入力されない

一点注意が必要なのは、bulk insertではModelクラスにて$timestampsをtrueに設定していても、created_atやupdated_atは自動入力されません。なぜならinsertメソッドはEloquent側ではなく、クエリビルダ側のメソッドだからです。したがって、insertするパラメタに明示的に含める必要があります。

まとめ

大量のレコードを挿入する場合、１レコードずつではなく、bulk insertで一括挿入することでとても速く処理できます。これは逆にDBへのクエリ発行がプログラムにおいて如何に重い処理か、という事を示しています。普段コードを書く際にも無駄なクエリを発行していないか気をつけねば、と思った次第です。

DB変更履歴の作成（４）パッケージ

Sun, 07 Jun 2020 04:55:17 +0900

DB変更の履歴の作成をトレイトで簡単にEloquentのモデルに装着できるとしたころまでが前回ですが、巷では似たような仕組みでより良いパッケージがすでにあります。今回はそれを紹介します。

Laravel Auditing

パッケージは、Laravel Auditingという名でララベル専用です。

独自のサイトもあります。

http://www.laravel-auditing.com/

まずはインストール、

$ composer require owen-it/laravel-auditing

次に設定ファイルのパブリッシュ。

$ php artisan vendor:publish --provider "OwenIt\Auditing\AuditingServiceProvider" --tag="config"

config/audit.phpが作成されます。

DBテーブルの作成が必要なので、以下を実行してmigrationファイルを作成します。

$ php artisan vendor:publish --provider "OwenIt\Auditing\AuditingServiceProvider" --tag="migrations"

作成されたファイルを見てみましょう。

database/migrations/2020_06_05_152546_create_audits_table.php

use Illuminate\Database\Migrations\Migration;
use Illuminate\Database\Schema\Blueprint;
use Illuminate\Support\Facades\Schema;

class CreateAuditsTable extends Migration
{
    /**
     * Run the migrations.
     *
     * @return void
     */
    public function up()
    {
        Schema::create('audits', function (Blueprint $table) {
            $table->bigIncrements('id');
            $table->string('user_type')->nullable();
            $table->unsignedBigInteger('user_id')->nullable();
            $table->string('event');
            $table->morphs('auditable');
            $table->text('old_values')->nullable();
            $table->text('new_values')->nullable();
            $table->text('url')->nullable();
            $table->ipAddress('ip_address')->nullable();
            $table->string('user_agent', 1023)->nullable();
            $table->string('tags')->nullable();
            $table->timestamps();

            $table->index(['user_id', 'user_type']);
        });
    }

    /**
     * Reverse the migrations.
     *
     * @return void
     */
    public function down()
    {
        Schema::drop('audits');
    }
}

これを見ると、作成するDBテーブルの名前はauditsで、 user_type, user_idは、アクセスしたユーザーの情報、 old_valuesとnew_valuesはモデルの古い値と新規の値が入る、 url、ip_address, user_agentはウェブのどこからアクセスされたかの情報、などと検討できますが、その他の項目はどう使われるが興味あるところです。特に、morphs(‘auditable’)の部分はなんでしょう？見たことないですね。

とりあえず、migrateしてテーブルを作成します。

$ php artisan migrate       
Migrating: 2020_06_05_152546_create_audits_table
Migrated:  2020_06_05_152546_create_audits_table (0.04 seconds)

作成されたテーブルの構造を見ると、

mysql> describe audits;
+----------------+---------------------+------+-----+---------+----------------+
| Field          | Type                | Null | Key | Default | Extra          |
+----------------+---------------------+------+-----+---------+----------------+
| id             | bigint(20) unsigned | NO   | PRI | NULL    | auto_increment |
| user_type      | varchar(255)        | YES  |     | NULL    |                |
| user_id        | bigint(20) unsigned | YES  | MUL | NULL    |                |
| event          | varchar(255)        | NO   |     | NULL    |                |
| auditable_type | varchar(255)        | NO   | MUL | NULL    |                |
| auditable_id   | bigint(20) unsigned | NO   |     | NULL    |                |
| old_values     | text                | YES  |     | NULL    |                |
| new_values     | text                | YES  |     | NULL    |                |
| url            | text                | YES  |     | NULL    |                |
| ip_address     | varchar(45)         | YES  |     | NULL    |                |
| user_agent     | varchar(1023)       | YES  |     | NULL    |                |
| tags           | varchar(255)        | YES  |     | NULL    |                |
| created_at     | timestamp           | YES  |     | NULL    |                |
| updated_at     | timestamp           | YES  |     | NULL    |                |
+----------------+---------------------+------+-----+---------+----------------+

$table->morphs(‘auditable’);は、auditable_typeとauditable_idの２つの項目が作成される結果となっていますが、何の値が入るのでしょうね。

モデルでの設定

さて、実際にモデルに設定してみましょう。私の仕組みと同様にトレイト(Auditable)を使用しますが、同じ名前のインターフェース(Auditable)も使われています。以下の「これが必要！」の部分です。

app/User.php

namespace App;

use Illuminate\Contracts\Auth\MustVerifyEmail;
use Illuminate\Foundation\Auth\User as Authenticatable;
use Illuminate\Notifications\Notifiable;
use Request;

use OwenIt\Auditing\Contracts\Auditable; // これが必要！

class User extends Authenticatable implements Auditable　// これが必要！
{
    use Notifiable;
    use \OwenIt\Auditing\Auditable; // これが必要！

    /**
     * The attributes that are mass assignable.
     *
     * @var array
     */
    protected $fillable = [
        'name', 'email', 'password',
    ];

    /**
     * The attributes that should be hidden for arrays.
     *
     * @var array
     */
    protected $hidden = [
        'password', 'remember_token',
    ];

    /**
     * The attributes that should be cast to native types.
     *
     * @var array
     */
    protected $casts = [
        'email_verified_at' => 'datetime',
    ];

    /**
     * ここで監査したい項目を指定！
     *
     * @var array
     */
    protected $auditInclude = [
        'name',
        'email',
    ];

早速、tinkerで実行してみましょう。 tinkerはコンソールの実行なので、設定ファイルを以下のように変更する必要あります。

config/audit.php

...
   /*
    |--------------------------------------------------------------------------
    | Audit Console
    |--------------------------------------------------------------------------
    |
    | Whether console events should be audited (eg. php artisan db:seed).
    |
    */

    'console' => true,
];

Psy Shell v0.10.4 (PHP 7.2.16 — cli) by Justin Hileman
>>> User::truncate(); //　リセットして空にします。
>>> $user = User::create(['name' => 'name1', 'email' => 'test1@example.com', 'password' => 'test']);
[!] Aliasing 'User' to 'App\User' for this Tinker session.
=> App\User {#3995
     name: "name1",
     email: "test1@example.com",
     updated_at: "2020-06-05 17:01:38",
     created_at: "2020-06-05 17:01:38",
     id: 1,
   }
>>> $user->update(['email' => 'test2@example.com']);
=> true
>>> $user->audits; // 作成した監査レコードを取得
=> Illuminate\Database\Eloquent\Collection {#4005
     all: [
       OwenIt\Auditing\Models\Audit {#4021
         id: 1,
         user_type: null,
         user_id: null,
         event: "created",
         auditable_type: "App\User",
         auditable_id: 1,
         old_values: "[]",
         new_values: "{"name":"name1","email":"test1@example.com"}",
         url: "console",
         ip_address: "127.0.0.1",
         user_agent: "Symfony",
         tags: null,
         created_at: "2020-06-05 17:01:38",
         updated_at: "2020-06-05 17:01:38",
       },
       OwenIt\Auditing\Models\Audit {#4026
         id: 2,
         user_type: null,
         user_id: null,
         event: "updated",
         auditable_type: "App\User",
         auditable_id: 1,
         old_values: "{"email":"test1@example.com"}",
         new_values: "{"email":"test2@example.com"}",
         url: "console",
         ip_address: "127.0.0.1",
         user_agent: "Symfony",
         tags: null,
         created_at: "2020-06-05 17:01:43",
         updated_at: "2020-06-05 17:01:43",
       },
     ],
   }

なるほど、

         auditable_type: "App\User",
         auditable_id: 1,

これらの項目には、何のモデルのどのレコードの履歴という情報を残しているのですね。

引き続いて、レコード削除も試みると、

>>> $user->delete();
=> true
>>> DB::table('audits')->get();
=> Illuminate\Support\Collection {#3986
     all: [
       {#4019
         +"id": 1,
         +"user_type": null,
         +"user_id": null,
         +"event": "created",
         +"auditable_type": "App\User",
         +"auditable_id": 1,
         +"old_values": "[]",
         +"new_values": "{"name":"name1","email":"test1@example.com"}",
         +"url": "console",
         +"ip_address": "127.0.0.1",
         +"user_agent": "Symfony",
         +"tags": null,
         +"created_at": "2020-06-05 17:01:38",
         +"updated_at": "2020-06-05 17:01:38",
       },
       {#4025
         +"id": 2,
         +"user_type": null,
         +"user_id": null,
         +"event": "updated",
         +"auditable_type": "App\User",
         +"auditable_id": 1,
         +"old_values": "{"email":"test1@example.com"}",
         +"new_values": "{"email":"test2@example.com"}",
         +"url": "console",
         +"ip_address": "127.0.0.1",
         +"user_agent": "Symfony",
         +"tags": null,
         +"created_at": "2020-06-05 17:01:43",
         +"updated_at": "2020-06-05 17:01:43",
       },
       {#4032
         +"id": 3,
         +"user_type": null,
         +"user_id": null,
         +"event": "deleted",
         +"auditable_type": "App\User",
         +"auditable_id": 1,
         +"old_values": "{"name":"name1","email":"test2@example.com"}",
         +"new_values": "[]",
         +"url": "console",
         +"ip_address": "127.0.0.1",
         +"user_agent": "Symfony",
         +"tags": null,
         +"created_at": "2020-06-05 17:04:27",
         +"updated_at": "2020-06-05 17:04:27",
       },
     ],
   }

削除されたレコードゆえにUser::find()では取得できないので、クエリビルダーで取得しましたが、３番目のauditsのレコードが作成されていること確認できます。また、eventの項目に注目してもらうと、created, updated, deletedという値が入っていることも確認できます。

今回はここまでですが、他にもタグを追加できる機能や、古いレコードを自動的に削除する機能など将来紹介したい機能がたくさんあります。また、クラス定義のインターフェイス、つまり、implementsや、よく知らないmorphsのトピックも将来扱いたいです。

DB変更履歴の作成（３）トレイト

Sun, 31 May 2020 01:34:51 +0900

前回のDB変更履歴保存のメカニズムは、Userのモデルのためだけですが、どのモデルでも同様なことが簡単にできるようにトレイトを作成してみます。

まず、audit_logsのテーブルを作成し直します。

どのモデルかわかるように項目を増やしました。前回、Userモデルのキーという意味でuser_idとしたところは、使用した会員のidの値が入るように変更しました。そして、モデルのキーは、model_keyという項目となっています。

database/migrations/2020_05_28_171205_create_audit_logs_table.php

use Illuminate\Database\Migrations\Migration;
use Illuminate\Database\Schema\Blueprint;
use Illuminate\Support\Facades\Schema;

class CreateAuditLogsTable extends Migration
{
    /**
     * Run the migrations.
     *
     * @return void
     */
    public function up()
    {
        Schema::create('audit_logs', function (Blueprint $table) {
            $table->bigIncrements('id');
            $table->string('route')->nullable(); // 実行したプログラムのルート
            $table->string('path')->nullable(); // 実行したプログラムのパス名
            $table->string('model')->nullable; // モデルのクラス名
            $table->unsignedBigInteger('model_key')->nullable(); // モデルのプライマリキー
            $table->unsignedBigInteger('user_id')->nullable(); // ユーザーのid
            $table->longText('old_value')->nullable(); // 変更前の値
            $table->longText('new_value')->nullable(); // 変更後の値
            $table->timestamps();
        });
    }

    /**
     * Reverse the migrations.
     *
     * @return void
     */
    public function down()
    {
        Schema::dropIfExists('audit_logs');
    }
}

次に、トレイトを作成します。

前回、boot()の関数名が、bootAuditTrait()と、‘boot’ + ‘AuditTrait’（トレイト名）となっていることに注意してください。

app/AuditTrait

namespace App;

use Request;
use Route;

trait AuditTrait
{
	/**
	 * Bootイベント
	 *
	 * 関数名は、boot()でなく'boot' + トレイト名
	 *
	 * @return void
	 */
	public static function bootAuditTrait()
	{
	    // parent::boot()はコールしない

        static::created(function ($model) {
            $model->addAuditLog('created');
        });

        static::updated(function ($model) {
            $model->addAuditLog('updated');
        });

        static::deleted(function ($model) {
            $model->addAuditLog('deleted');
        });
	}

    public function addAuditLog($event)
    {
        $route = optional(Route::getCurrentRoute())->getName();
        $path = Request::path();
        $model = get_class($this);
        $model_key = $this->id;
        $user_id = optional(auth()->user())->id;

        $old_value = $new_value = null;

        if (in_array($event, ['created', 'updated'])) {
            $new_value = serialize($this->attributes);
        }

        if (in_array($event, ['updated', 'deleted'])) {
            $old_value = serialize($this->original);
        }

        AuditLog::create([
            'route'      => $route,
            'path'       => $path,
            'model'      => $model,
            'model_key'  => $model_key,
            'user_id'    => $user_id,
            'old_value'  => $old_value,
            'new_value'  => $new_value,
        ]);
    }
}

上のトレイトにより、Userのクラスでは、use AuditTraittの１行の追加だけで済みます。

app/User.php

namespace App;

use Illuminate\Contracts\Auth\MustVerifyEmail;
use Illuminate\Foundation\Auth\User as Authenticatable;
use Illuminate\Notifications\Notifiable;
use Request;

class User extends Authenticatable
{
    use Notifiable;
    use AuditTrait;

    /**
     * The attributes that are mass assignable.
     *
     * @var array
     */
    protected $fillable = [
        'name', 'email', 'password',
    ];

    /**
     * The attributes that should be hidden for arrays.
     *
     * @var array
     */
    protected $hidden = [
        'password', 'remember_token',
    ];

    /**
     * The attributes that should be cast to native types.
     *
     * @var array
     */
    protected $casts = [
        'email_verified_at' => 'datetime',
    ];
}

さて、tinkerの出番です。変更をテストみましょう。

Psy Shell v0.10.4 (PHP 7.2.16 — cli) by Justin Hileman
>>> use App\AuditLog;

>>> $user = User::create(['name' => 'name1', 'email' => 'test1@example.com', 'password' => 'test']);
[!] Aliasing 'User' to 'App\User' for this Tinker session.
=> App\User {#3990
     name: "name1",
     email: "test1@example.com",
     updated_at: "2020-05-28 18:36:06",
     created_at: "2020-05-28 18:36:06",
     id: 1,
   }

>>> $user->update(['email' => 'test2@example.com']);
=> true

>>> $user->delete();
=> true

>>> AuditLog::all();
=> Illuminate\Database\Eloquent\Collection {#4015
     all: [
       App\AuditLog {#4016
         id: 1,
         route: null,
         path: "/",
         model: "App\User",
         model_key: 1,
         user_id: null,
         old_value: null,
         new_value: "a:6:{s:4:"name";s:5:"name1";s:5:"email";s:17:"test1@example.com";s:8:"password";s:4:"test";s:10:"updated_at";s:19:"2020-05-28 18:36:06";s:10:"created_at";s:19:"2020-05-28 18:36:06";s:2:"id";i:1;}",
         created_at: "2020-05-28 18:36:06",
         updated_at: "2020-05-28 18:36:06",
       },
       App\AuditLog {#4017
         id: 2,
         route: null,
         path: "/",
         model: "App\User",
         model_key: 1,
         user_id: null,
         old_value: "a:6:{s:4:"name";s:5:"name1";s:5:"email";s:17:"test1@example.com";s:8:"password";s:4:"test";s:10:"updated_at";s:19:"2020-05-28 18:36:06";s:10:"created_at";s:19:"2020-05-28 18:36:06";s:2:"id";i:1;}",
         new_value: "a:6:{s:4:"name";s:5:"name1";s:5:"email";s:17:"test2@example.com";s:8:"password";s:4:"test";s:10:"updated_at";s:19:"2020-05-28 18:36:10";s:10:"created_at";s:19:"2020-05-28 18:36:06";s:2:"id";i:1;}",
         created_at: "2020-05-28 18:36:10",
         updated_at: "2020-05-28 18:36:10",
       },
       App\AuditLog {#4018
         id: 3,
         route: null,
         path: "/",
         model: "App\User",
         model_key: 1,
         user_id: null,
         old_value: "a:6:{s:4:"name";s:5:"name1";s:5:"email";s:17:"test2@example.com";s:8:"password";s:4:"test";s:10:"updated_at";s:19:"2020-05-28 18:36:10";s:10:"created_at";s:19:"2020-05-28 18:36:06";s:2:"id";i:1;}",
         new_value: null,
         created_at: "2020-05-28 18:36:14",
         updated_at: "2020-05-28 18:36:14",
       },
     ],
   }
>>>

前回と同様に、レコードの作成、編集、削除のすべてが、audit_logsのレコードに記録されています。

DB変更履歴の作成（２）監査のデータを保存

Sun, 24 May 2020 03:33:06 +0900

前回においては、Eloquentのbootメソッドを利用してDB変更の情報（監査の情報）を取得することができました。今回は、これをDBに記録する部分を考えてみましょう。

監査のデータを保存するテーブル

監査のデータを保存するテーブルを、audit_logsとしてmigrationファイルを作成します。

$ php artisan make:migration create_audit_logs_table  
Created Migration: 2020_05_20_024714_create_audit_logs_table

作成されたファイルを編集して、テーブルの項目定義を入れます。

database/migrations/2020_05_20_024714_create_audit_logs_table

use Illuminate\Database\Migrations\Migration;
use Illuminate\Database\Schema\Blueprint;
use Illuminate\Support\Facades\Schema;

class CreateAuditLogsTable extends Migration
{
    /**
     * Run the migrations.
     *
     * @return void
     */
    public function up()
    {
        Schema::create('audit_logs', function (Blueprint $table) {
            $table->bigIncrements('id');
            $table->unsignedBigInteger('user_id')->default(0)->index(); // Userモデルのid
            $table->string('path')->default(''); // 実行したプログラムのパス名
            $table->longText('old_value')->nullable(); // 変更前の値
            $table->longText('new_value')->nullable(); // 変更後の値
            $table->timestamps();
        });
    }

    /**
     * Reverse the migrations.
     *
     * @return void
     */
    public function down()
    {
        Schema::dropIfExists('audit_logs');
    }

old_valueとnew_valueには、レコードの項目のすべての値をserializeして入れるために大きいデータタイプとしています。

以下を実行してテーブルを作成します。

$ php artisan migrate
Migrating: 2020_05_20_024714_create_audit_logs_table
Migrated:  2020_05_20_024714_create_audit_logs_table (0.02 seconds)

AuditLogのクラスも作成します。

app/AuditLog

namespace App;

use Illuminate\Database\Eloquent\Model;

class AuditLog extends Model
{
    protected $guarded = [];
}

そして、Userクラスのプログラムを書き替えます。

app/User.php

namespace App;

use Illuminate\Contracts\Auth\MustVerifyEmail;
use Illuminate\Foundation\Auth\User as Authenticatable;
use Illuminate\Notifications\Notifiable;

use Request;

class User extends Authenticatable
{
    use Notifiable;

    /**
     * The attributes that are mass assignable.
     *
     * @var array
     */
    protected $fillable = [
        'name', 'email', 'password',
    ];

    /**
     * The attributes that should be hidden for arrays.
     *
     * @var array
     */
    protected $hidden = [
        'password', 'remember_token',
    ];

    /**
     * The attributes that should be cast to native types.
     *
     * @var array
     */
    protected $casts = [
        'email_verified_at' => 'datetime',
    ];

    protected static function boot()
    {
        parent::boot();

        static::created(function ($model) {
            AuditLog::create([
                'user_id'    => $model->id,
                'path'       => Request::path(),
                'old_value'  => null,
                'new_value'  => serialize($model->attributes),
            ]);
        });

        static::updated(function ($model) {
            AuditLog::create([
                'user_id'    => $model->id,
                'path'       => Request::path(),
                'old_value'  => serialize($model->original),
                'new_value'  => serialize($model->attributes),
            ]);
        });

        static::deleted(function ($model) {
            AuditLog::create([
                'user_id'    => $model->id,
                'path'       => Request::path(),
                'old_value'  => serialize($model->original),
                'new_value'  => null,
            ]);
        });
    }
}

tinkerでレコードの作成、Eメールアドレスの変更、そしてレコードの削除を実行します。

Psy Shell v0.10.2 (PHP 7.2.16 — cli) by Justin Hileman
>>> use App\AuditLog;
>>> $user = User::create(['name' => 'name1', 'email' => 'test1@example.com', 'password' => 'test']);
[!] Aliasing 'User' to 'App\User' for this Tinker session.
=> App\User {#3058
     name: "name1",
     email: "test1@example.com",
     updated_at: "2020-05-20 03:28:18",
     created_at: "2020-05-20 03:28:18",
     id: 1,
   }
>>> $user->update(['email' => 'test2@example.com']);
=> true
>>> $user->delete();
=> true

AuditLogのレコードを取り出してみると、すべてのの変更履歴、監査の情報が保存されています。

>>> AuditLog::all();
=> Illuminate\Database\Eloquent\Collection {#3072
     all: [
       App\AuditLog {#3073
         id: 1,
         user_id: 1,
         path: "/",
         old_value: null,
         new_value: "a:6:{s:4:"name";s:5:"name1";s:5:"email";s:17:"test1@example.com";s:8:"password";s:4:"test";s:10:"updated_at";s:19:"2020-05-20 03:28:18";s:10:"created_at";s:19:"2020-05-20 03:28:18";s:2:"id";i:1;}",
         created_at: "2020-05-20 03:28:18",
         updated_at: "2020-05-20 03:28:18",
       },
       App\AuditLog {#3074
         id: 2,
         user_id: 1,
         path: "/",
         old_value: "a:6:{s:4:"name";s:5:"name1";s:5:"email";s:17:"test1@example.com";s:8:"password";s:4:"test";s:10:"updated_at";s:19:"2020-05-20 03:28:18";s:10:"created_at";s:19:"2020-05-20 03:28:18";s:2:"id";i:1;}",
         new_value: "a:6:{s:4:"name";s:5:"name1";s:5:"email";s:17:"test2@example.com";s:8:"password";s:4:"test";s:10:"updated_at";s:19:"2020-05-20 03:28:38";s:10:"created_at";s:19:"2020-05-20 03:28:18";s:2:"id";i:1;}",
         created_at: "2020-05-20 03:28:38",
         updated_at: "2020-05-20 03:28:38",
       },
       App\AuditLog {#3075
         id: 3,
         user_id: 1,
         path: "/",
         old_value: "a:6:{s:4:"name";s:5:"name1";s:5:"email";s:17:"test2@example.com";s:8:"password";s:4:"test";s:10:"updated_at";s:19:"2020-05-20 03:28:38";s:10:"created_at";s:19:"2020-05-20 03:28:18";s:2:"id";i:1;}",
         new_value: null,
         created_at: "2020-05-20 03:28:47",
         updated_at: "2020-05-20 03:28:47",
       },
     ],
   }

DBの変更履歴の作成

Mon, 18 May 2020 11:58:18 +0900

データベースに保存されているデータはいつも現時点での値であり、過去の値は保存されていません。しかし、レコードのデータがどう変更したかという情報は重要です。どう変更したかだけではなく、誰がいつ、アプリのどの機能を使用して、さらにはどういう理由で、という情報も必要になってきます。例えば、カスタマサポートにおいて、会員の住所が変更されて注文した商品が届かなかったとき、それらの情報があれば、いついつにお客様が住所を変更しましたね、とか即答できます。さて、これらの変更イベント時の変更情報（監査あるいはAudit情報）、Laravelではどのように効率的にDBに保存することが可能でしょうか？

Eloquentのイベントメソッド

LaravelのEloquentを利用すると、DBのイベント、つまりレコードの作成、変更、削除の３つのイベントに連結したメソッドが提供されています。そして、それらのイベントが発生する前あるいは後においてユーザー定義のコードをコールバックさせることが可能です。これらを利用したら、希望するAuditの情報をキャプチャすることが簡単にできます。

さてLaravelのデフォルトのプロジェクトを使って見てみましょう。まず、UserのクラスにDBのレコード変更後のイベントのコールバックを作成します。以下のようにbootメソッドにおいて見慣れないクラスメソッドupdatedをコールすることで可能となります。

app/User.php

namespace App;

use Illuminate\Contracts\Auth\MustVerifyEmail;
use Illuminate\Foundation\Auth\User as Authenticatable;
use Illuminate\Notifications\Notifiable;

class User extends Authenticatable
{
    use Notifiable;
...
    protected static function boot()
    {
        parent::boot();

        static::updated(function () {
            echo "updated\n";
        });
    }
}

ちなみに、updatedは更新後にコールされるものですが、新規作成後は、created、削除後はdeletedというメソッドになります。

tinkerを使用して実行してみます。

>>> $user = User::find(1);
=> App\User {#3048
     id: 1,
     name: "近藤 篤司",
     email: "manabu.takahashi@example.net",
     email_verified_at: "2020-02-13 04:27:15",
     created_at: "2020-02-13 04:27:15",
     updated_at: "2020-05-17 18:31:32",
   }
>>> $user->update(['email' => 'test@example.com']);
updated
=> true

コールバックで定義したupdatedが表示されましたね！

変更前後の情報の取得

DBのレコード変更イベントでユーザー定義の関数をコールバックを確認できたら、次は変更前後でのレコードの情報をどうやって取得するかです。以下見てください。コールバックにそれらの情報を表示するコードを追加しました。

app/User.php

namespace App;

use Illuminate\Contracts\Auth\MustVerifyEmail;
use Illuminate\Foundation\Auth\User as Authenticatable;
use Illuminate\Notifications\Notifiable;

class User extends Authenticatable
{
    use Notifiable;
...
    protected static function boot()
    {
        parent::boot();

        static::updated(function ($model) {
            echo "updated\n";
            print_r($model->original);
            print_r($model->attributes);
        });
    }
}

tinkerで実行してみます。

>>> $user = User::find(1);
[!] Aliasing 'User' to 'App\User' for this Tinker session.
=> App\User {#3067
     id: 1,
     name: "近藤 篤司",
     email: "test@example.com",
     email_verified_at: "2020-02-13 04:27:15",
     created_at: "2020-02-13 04:27:15",
     updated_at: "2020-05-17 18:59:31",
   }
>>> $user->update(['email' => 'test2@example.com']);
updated
Array
(
    [id] => 1
    [name] => 近藤 篤司
    [email] => test@example.com
    [email_verified_at] => 2020-02-13 04:27:15
    [password] => $2y$10$92IXUNpkjO0rOQ5byMi.Ye4oKoEa3Ro9llC/.og/at2.uheWG/igi
    [remember_token] => cDvZkS5nOA
    [created_at] => 2020-02-13 04:27:15
    [updated_at] => 2020-05-17 18:59:31
)
Array
(
    [id] => 1
    [name] => 近藤 篤司
    [email] => test2@example.com
    [email_verified_at] => 2020-02-13 04:27:15
    [password] => $2y$10$92IXUNpkjO0rOQ5byMi.Ye4oKoEa3Ro9llC/.og/at2.uheWG/igi
    [remember_token] => cDvZkS5nOA
    [created_at] => 2020-02-13 04:27:15
    [updated_at] => 2020-05-17 19:03:27
)
=> true

前後の値、キャプチャできましたね。これで変更履歴を作成するには十分な準備ができました。これらを利用すれば、変更前後の値あるいは差分を保存できますね。

DBの負荷の緩和（２）トランザクション

Mon, 20 Apr 2020 02:31:25 +0900

前回において、Laravelの読み込みと書き込みのDBを自動使い分け機能により、プログラムの設定だけで簡単にDB負荷を緩和できることを知りました。今回は、DBのトランザクションにおいてその機能の振る舞いをチェックしてみます。

例えば、以前の個数管理での在庫数変更の以下の例を見てます。

$product = Product::find(1);　// 複製のDBから読み込む
 
$product->update(['inventory' => $product->inventory - 1]); // マスターのDBで書き込む

上では、まず、商品の情報をDBから読み込み、そこから得る在庫数をもとに次の行で在庫数を変更します。しかし、２つのDBを使用するとなると、最初の行は複製DBからの読み込みとなり、次の行ではマスターのDBにおいての書き込みとなります。

問題は、複製のDBはマスターDBとの時間差があるので、もしかしたら最初の行で読み込んだのは最新の在庫数ではないかもしれないません。つまりデータの整合性の問題となる可能性です。

そうなら、以下のようにトランザクションで囲んでみましょう。

DB::beginTransaction();
 
$product = Product::find(1);
 
$product->update(['inventory' => $product->inventory - 1]);
 
DB::commit();

しかし、トランザクションはマスターDB内だけでの作業の整合性を保証するものなので、同じ問題となるのでは？

Laravelのコードを深く追ってみます。

まず、LaravelのDB接続のクラスでは、マスターDBの$pdoと読み込み専用の$readPdoの２つのDB接続のための変数が宣言されています。

/vendor/laravel/framework/src/Illuminate/Database/Connection.php

...
class Connection implements ConnectionInterface
{
    use DetectsDeadlocks,
        DetectsLostConnections,
        Concerns\ManagesTransactions;

    /**
     * The active PDO connection.
     *
     * @var \PDO|\Closure
     */
    protected $pdo;

    /**
     * The active PDO connection used for reads.
     *
     * @var \PDO|\Closure
     */
    protected $readPdo;
...

そして、同じクラス内で、読み込みDBの接続の取得は、以下のメソッドで定義されています。

    /**
     * Get the current PDO connection used for reading.
     *
     * @return \PDO
     */
    public function getReadPdo()
    {
        if ($this->transactions > 0) { //トランザクションがあると、マスターのDB接続を使用
            return $this->getPdo();
        }

        if ($this->recordsModified && $this->getConfig('sticky')) {
            return $this->getPdo();
        }

        if ($this->readPdo instanceof Closure) {
            return $this->readPdo = call_user_func($this->readPdo);
        }

        return $this->readPdo ?: $this->getPdo();
    }
...

トランザクションがあると、読み込み専用のDBではなく、マスターのDBが使われる条件文があります。つまり、トランザクションの中では、たとえDB実行文が読み込み（SELECT SQL文）であっても、読み込みのDB接続は使われずマスターDBしか使われないということです。

ちなみに、上のコードではstickyのときも、条件文で読み込みのDBの使用しないようになっています。これは以下のようにデータベースの設定で指定できます。そして、目的はDB更新後に、書き込みをしたマスターDBから値を読みたいときです。トランザクションと同様に、読み込み専用のDBからでは時間差の問題が生ずるからです。良く考えられていますね。

config/database.php

...
'mysql' => [
    'read' => [
        'host' => [
            '192.168.1.1',
            '196.168.1.2',
        ],
    ],
    'write' => [
        'host' => [
            '196.168.1.3',
         ],
    ],
    'sticky'    => true,
    'driver'    => 'mysql',
    'database'  => 'database',
    'username'  => 'root',
    'password'  => '',
    'charset'   => 'utf8mb4',
    'collation' => 'utf8mb4_unicode_ci',
    'prefix'    => '',
],
...

個数管理：実用を考えたケース

Sun, 05 Apr 2020 01:41:59 +0900

前回の「個数管理」のコードに少し肉付けをして実際に近いケースを考慮してみます。

例えば、Ｅコマースにおいてチェックアウトの際にカートに追加したアイテムの在庫を確保するとします。しかし、カートには複数のアイテムが含まれるかもしれないので、すべてのアイテムにおいて在庫確保成功とはいかないかもしれません。在庫数の更新失敗のアイテムがあるときにはすでに在庫確保したアイテムも元に戻す必要あります。

Checkoutというクラスを作成し、reserveInventoryというメソッドを作成します。 DBのトランザクションとカスタムExceptionに注目してください。

App/Checkout.php

namespace App;

use DB;
use Exception;
use App\Product;
use App\Exceptions\InventoryException;

use Illuminate\Database\Eloquent\Model;

class Checkout extends Model
{
    public static function reserveInventory($ids)
    {
        try {
            DB::beginTransaction();

            foreach($ids as $id  => $quantity) {
                $count = Product::query()
                    ->where('id', '=', $id)
                    ->whereRaw("inventory - $quantity >= 0")
                    ->decrement('inventory', $quantity);

                if ($count == 0) {
                    throw new InventoryException(); // 在庫がなくて在庫数を更新できなかったとき
                }
            }

            DB::commit();

        } catch (InventoryException $e) {
            DB::rollBack();

            return '購入しようとしている商品の在庫が十分にありません';

        } catch (Exception $e) {
            DB::rollBack();

            return 'DBエラーが発生しました' . $e->getMessage();
        }

        return '在庫確保成功！';
    }
}

reserveInventory()の引数は、product.idとquantityの値の配列関数です。例えば、product.id = 1で購入個数１個なら、[ 1 => 2 ]。

上で使用されている、InventoryExceptionの定義は、

App/ExceptionsInventoryException.php

namespace App\Exceptions;

use Exception;

class InventoryException extends Exception
{
    public function __construct($message = '') {
        parent::__construct($message);
    }
}

さて、tinkerで実行してみましょう。

まず、商品を２つ用意します。商品１の在庫は２で、商品２の在庫は１とします。

>>> App\Product::all()
=> Illuminate\Database\Eloquent\Collection {#3059
     all: [
       App\Product {#3083
         id: 1,
         name: "商品1",
         price: "1000",
         inventory: 2,
         created_at: "2020-03-27 19:35:37",
         updated_at: "2020-04-02 23:06:36",
       },
       App\Product {#3071
         id: 2,
         name: "商品2",
         price: "2000",
         inventory: 1,
         created_at: "2020-04-02 23:05:52",
         updated_at: "2020-04-02 23:05:52",
       },
     ],
   }

次に、カートのアイテムを用意して在庫確保します。

商品１を１個、商品２を１個購入です。

>>> $products = [ 1 => 1, 2 => 1 ];
=> [
     1 => 1,
     2 => 1,
   ]
>>> Cart::reserveInventory($products);
=> "在庫確保成功！"
>>> App\Product::all();
=> Illuminate\Database\Eloquent\Collection {#3060
     all: [
       App\Product {#3075
         id: 1,
         name: "商品1",
         price: "1000",
         inventory: 1,
         created_at: "2020-03-27 19:35:37",
         updated_at: "2020-04-02 23:08:53",
       },
       App\Product {#3078
         id: 2,
         name: "商品2",
         price: "2000",
         inventory: 0,
         created_at: "2020-04-02 23:05:52",
         updated_at: "2020-04-02 23:08:53",
       },
     ],
   }

商品１の在庫は１で、商品２の在庫は０となりました。うまく在庫数に反映されています。

更新失敗を見るために、もう１度在庫確保を実行してみます。

>>> Cart::reserveInventory($products);
=> "購入しようとしている商品の在庫が十分にありません"
>>> App\Product::all();
=> Illuminate\Database\Eloquent\Collection {#3070
     all: [
       App\Product {#3072
         id: 1,
         name: "商品1",
         price: "1000",
         inventory: 1,
         created_at: "2020-03-27 19:35:37",
         updated_at: "2020-04-02 23:08:53",
       },
       App\Product {#3082
         id: 2,
         name: "商品2",
         price: "2000",
         inventory: 0,
         created_at: "2020-04-02 23:05:52",
         updated_at: "2020-04-02 23:08:53",
       },
     ],
   }

今度は、在庫エラーが出ました。商品１は更新されますが、商品２においては在庫がないのでInventoryExceptionがthrowされ、トランザクションのためにDBへの変更はロールバックされて商品１の変更ももとに戻ります。

以上は、シンプル化された例なので、改良点はたくさんありそうです。エラー文に商品名を入れるとか、在庫エラーを管理者にメールで伝えるとか。

個数管理

Sat, 28 Mar 2020 05:46:15 +0900

商品の在庫数管理など一般的な個数管理に必要とされる、Eloquentのメソッドdecrementを紹介します。

準備

まず、商品テーブルの作成からです。migrationを作成します。

$ php artisan make:migration create_products_table --create=products

作成されたファイルを編集して、name, price, inventoryの項目を追加します。

use Illuminate\Database\Migrations\Migration;
use Illuminate\Database\Schema\Blueprint;
use Illuminate\Support\Facades\Schema;

class CreateProductsTable extends Migration
{
    /**
     * Run the migrations.
     *
     * @return void
     */
    public function up()
    {
        Schema::create('products', function (Blueprint $table) {
            $table->bigIncrements('id');
            $table->char('name', 100); // 商品名
            $table->decimal('price', 10, 0);　// 価格
            $table->smallInteger('inventory'); // 在庫数
            $table->timestamps();
        });
    }

    /**
     * Reverse the migrations.
     *
     * @return void
     */
    public function down()
    {
        Schema::dropIfExists('products');
    }
}

これをmigrateしてテーブルを作成します。

$ php artisan migrate

次に、tinkerを立ち上げて商品レコードを作成します。

$ php artisan tinker
Psy Shell v0.9.12 (PHP 7.2.16 — cli) by Justin Hileman
>>> use App\Product;
>>> Product::create(['name' => '商品', 'price' => 1000, 'inventory' => 10]);
=> App\Product {#3064
     name: "商品",
     price: 1000,
     inventory: 10,
     updated_at: "2020-03-27 19:35:37",
     created_at: "2020-03-27 19:35:37",
     id: 1,
   }

トランザクションで整合性を保持

商品の在庫から購入数分だけ差し引く処理として、まず考えられるのは以下のようになります（引き続きtinkerを使用します）。

>>> use App\Product;
>>> $product = Product::find(1);
=> App\Product {#3056
     id: 1,
     name: "商品",
     price: "1000",
     inventory: 10,
     created_at: "2020-03-27 19:35:37",
     updated_at: "2020-03-27 20:03:27",
   }
>>> $product->update(['inventory' => $product->inventory - 1]);
=> true
>>> $product->refresh();
=> App\Product {#3056
     id: 1,
     name: "商品",
     price: "1000",
     inventory: 9,
     created_at: "2020-03-27 19:35:37",
     updated_at: "2020-03-27 20:04:56",
   }
>>>

つまり、商品をオブジェクトに読み込んで、現在の在庫数の属性（inventory）の値から、必要な個数（ここでは１個）を引いた値でDBレコードを更新（update）します。

上で実行されたSQL文を確認のために見てみましょう。レコード読み込み、更新、さらに読み込みと３つのSQL文となります。

>>> sql();
=> [
     [
       "query" => "select * from `products` where `products`.`id` = ? limit 1",
       "bindings" => [
         1,
       ],
       "time" => 14.83,
     ],
     [
       "query" => "update `products` set `inventory` = ?, `products`.`updated_at` = ? where `id` = ?",
       "bindings" => [
         9,
         "2020-03-27 20:04:56",
         1,
       ],
       "time" => 5.79,
     ],
     [
       "query" => "select * from `products` where `products`.`id` = ? limit 1",
       "bindings" => [
         1,
       ],
       "time" => 8.23,
     ],
   ]

このやり方、一見良さそうに見えますが、大きな問題があります。

ウェブのように同時に同じ処理が可能な環境において、レコードを読み込んだ時と書き込むときの間に在庫数がすでに更新されているかもしれないことです。その場合には在庫数は不正確になってしまいます。

これを防ぐには、上のプログラムをトランザクションで囲むことです。

DB::beginTransaction();

$product = Product::find(1);

$product->update(['inventory' => $product->inventory - 1]);

DB::commit();

トランザクションでは複数のSQL文の実行があたかも１つのように実行してくれるので、その間の作業の整合性を保持してれます。

よりシンプルに

先のトランザクションでも問題ないですが、以下のようEloquentのdecrementのメソッドを使用して同様な処理も可能です。

>>> Product::where('id', '=', 1)->decrement('inventory', 1);
=> 1
>>> sql();
=> [
     [
       "query" => "update `products` set `inventory` = `inventory` - 1, `products`.`updated_at` = ? where `id` = ?",
       "bindings" => [
         "2020-03-27 20:18:48",
         1,
       ],
       "time" => 9.34,
     ],
   ]

こうなるとSQL文は１つなので、整合性保持のためのトランザクションの必要はなくなります。

さて、注意する必要があるのは、上の例を見て、以下でも同じことができるのでは？と思われることです。

>>> Product::find(1)->decrement('inventory', 1);
=> 1

しかし、このSQL文を見てみると、以下のように読み込みと更新の２つのSQL文になっています。これではトランザクションが必要となります。

>>> sql();
=> [
     [
       "query" => "select * from `products` where `products`.`id` = ? limit 1",
       "bindings" => [
         1,
       ],
       "time" => 12.63,
     ],
     [
       "query" => "update `products` set `inventory` = `inventory` - 1, `products`.`updated_at` = ? where `id` = ?",
       "bindings" => [
         "2020-03-27 20:22:48",
         1,
       ],
       "time" => 2.58,
     ],
   ]

在庫がゼロにならないようにするには

在庫数を減らすときに、在庫数がゼロにならないようにするには、チェックが必要です。これも以下のように実行するなら１つのSQL文で済みます。

>>> Product::where('id', '=', 1)->whereRaw('inventory - 1 >= 0')->decrement('inventory', 1);
=> 1
>>> sql();
=> [
     [
       "query" => "update `products` set `inventory` = `inventory` - 1, `products`.`updated_at` = ? where `id` = ? and inventory - 1 >= 0",
       "bindings" => [
         "2020-03-27 20:38:46",
         1,
       ],
       "time" => 10.09,
     ],
   ]

最初の行の実行で返り値が１となっていること気づいたと思いますが、そこでは更新されたレコードの数が返っています。

もし、実行の前の在庫数がすでにゼロなら、

>>> Product::where('id', '=', 1)->update(['inventory' => 0]);
=> 1
>>> Product::where('id', '=', 1)->whereRaw('inventory - 1 >= 0')->decrement('inventory', 1);
=> 0

０が返って更新はなかった、ということです。

マジックメソッド

Sun, 16 Feb 2020 02:48:42 +0900

LaravelのEloquentのModelを継承したクラスで定義できるアクセッサーはとても便利です。しかし、どうして、あたかもDBテーブルにある項目のようにアクセスできるのか不思議に思ったことありませんか？　

アクセッサー

例えば、以下のようにUserのモデルにgetEmailDomainAttribute()を定義します。

app/User.php

namespace App;

use Illuminate\Contracts\Auth\MustVerifyEmail;
use Illuminate\Foundation\Auth\User as Authenticatable;
use Illuminate\Notifications\Notifiable;

// 注意：AuthenticatableのもとのUserクラスは、EloquentのModelクラスを継承したクラスです。
class User extends Authenticatable
{
    use Notifiable;
...
    // users.emailのDB項目のドメイン名を返す
    public function getEmailDomainAttribute()
    {
        $array = explode('@', $this->email);
        return array_pop($array);
    }
}

以下のように、getEmailDomainAttribute()ではなく、email_domainと、モデルの属性のようにアクセスできます。

$ php artisan tinker
Psy Shell v0.9.12 (PHP 7.2.16 — cli) by Justin Hileman
>>> factory(App\User::class)->create();
=> App\User {#3039
     name: "近藤 篤司",
     email: "manabu.takahashi@example.net",
     email_verified_at: "2020-02-13 04:27:15",
     updated_at: "2020-02-13 04:27:15",
     created_at: "2020-02-13 04:27:15",
     id: 1,
   }
>>> User::find(1)->email_domain;
[!] Aliasing 'User' to 'App\User' for this Tinker session.
=> "example.net"
>>>

どうしたら、このようなことできるのでしょうか？

マジックメソッド

Laravelのアクセッサーのトリックは、実はPHPのマジックメソッドの__get()です。

まず、以下のようにFooというクラスで、__get()と__set()の２つのマジックメソッドのメソッドを定義します

app/Foo.php

namespace App;

class Foo {

    protected $attributes = [];

    public function __get( $key )
    {
        return $this->attributes[ $key ];
    }

    public function __set( $key, $value )
    {
        $this->attributes[ $key ] = $value;
    }
}

さて、これをtinkerでテストしてみると、

$ php artisan tinker
Psy Shell v0.9.12 (PHP 7.2.16 — cli) by Justin Hileman
>>> $foo = new App\Foo;
=> App\Foo {#3018}
>>> $foo->name = '名前'; // Foo::__set()がコールされる
=> "名前"
>>> $foo->name; // Foo::__get()がコールされる
=> "名前"

Laravelはこのメカニズムを拡張したものです。以下のLaravelのModelの定義を見てください。

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

namespace Illuminate\Database\Eloquent;

use ArrayAccess;
use Exception;
use Illuminate\Contracts\Queue\QueueableCollection;
use Illuminate\Contracts\Queue\QueueableEntity;
use Illuminate\Contracts\Routing\UrlRoutable;
use Illuminate\Contracts\Support\Arrayable;
use Illuminate\Contracts\Support\Jsonable;
use Illuminate\Database\ConnectionResolverInterface as Resolver;
use Illuminate\Database\Eloquent\Relations\Pivot;
use Illuminate\Support\Arr;
use Illuminate\Support\Collection as BaseCollection;
use Illuminate\Support\Str;
use Illuminate\Support\Traits\ForwardsCalls;
use JsonSerializable;

abstract class Model implements Arrayable, ArrayAccess, Jsonable, JsonSerializable, QueueableEntity, UrlRoutable
{
    use Concerns\HasAttributes,
        Concerns\HasEvents,
        Concerns\HasGlobalScopes,
        Concerns\HasRelationships,
        Concerns\HasTimestamps,
        Concerns\HidesAttributes,
        Concerns\GuardsAttributes,
        ForwardsCalls;
...
    /**
     * Dynamically retrieve attributes on the model.
     *
     * @param  string  $key
     * @return mixed
     */
    public function __get($key)
    {
        return $this->getAttribute($key);
    }

    /**
     * Dynamically set attributes on the model.
     *
     * @param  string  $key
     * @param  mixed  $value
     * @return void
     */
    public function __set($key, $value)
    {
        $this->setAttribute($key, $value);
    }
...

__get()と__set()が定義されていますね。

__get()で使用されている、getAttribute()は、HasAttributesのトレイトで定義されています。 HasAttributeを見てましょう。

vendor/laravel/framework/src/Illuminate/Database/Eloquent/Concerns/HasAttributes.php

namespace Illuminate\Database\Eloquent\Concerns;

use Carbon\CarbonInterface;
use DateTimeInterface;
use Illuminate\Contracts\Support\Arrayable;
use Illuminate\Database\Eloquent\JsonEncodingException;
use Illuminate\Database\Eloquent\Relations\Relation;
use Illuminate\Support\Arr;
use Illuminate\Support\Carbon;
use Illuminate\Support\Collection as BaseCollection;
use Illuminate\Support\Facades\Date;
use Illuminate\Support\Str;
use LogicException;

trait HasAttributes
{
...
    /**
     * Get a plain attribute (not a relationship).
     *
     * @param  string  $key
     * @return mixed
     */
    public function getAttributeValue($key)
    {
        $value = $this->getAttributeFromArray($key);

        // If the attribute has a get mutator, we will call that then return what
        // it returns as the value, which is useful for transforming values on
        // retrieval from the model to a form that is more useful for usage.
        if ($this->hasGetMutator($key)) {
            return $this->mutateAttribute($key, $value);
        }

        // If the attribute exists within the cast array, we will convert it to
        // an appropriate native PHP type dependant upon the associated value
        // given with the key in the pair. Dayle made this comment line up.
        if ($this->hasCast($key)) {
            return $this->castAttribute($key, $value);
        }

        // If the attribute is listed as a date, we will convert it to a DateTime
        // instance on retrieval, which makes it quite convenient to work with
        // date fields without having to create a mutator for each property.
        if (in_array($key, $this->getDates()) &&
            ! is_null($value)) {
            return $this->asDateTime($value);
        }

        return $value;
    }
...
    /**
     * Get the value of an attribute using its mutator.
     *
     * @param  string  $key
     * @param  mixed  $value
     * @return mixed
     */
    protected function mutateAttribute($key, $value)
    {
        return $this->{'get'.Str::studly($key).'Attribute'}($value);
    }
...

上の、mutateAttribute()において、$keyがemail_domainなら、

return $this->getEmailDomainAttribute($value)

となります。

マスアサインメントの保護を外す

Mon, 09 Sep 2019 07:12:25 +0900

今回は「マスアサインメントの保護を外す」という大胆なタイトルです。マスアサインメントの保護は、Eloquentにおけるモデルの定義においての$fillableや$guardedを通しての設定のことです。その保護を外す、とは、これを指定しない、ということではなく（もちろん外すのは危険）、あるケースにおいて外す必要が出てきたときに、どう外すかということです。

$fillable & $guarded

復習として、Eloquentにおけるこれらの変数の説明から始めます。

Laravelのプロジェクトのデフォルト設定のDBのusersのテーブルは以下のような構造です。

mysql> describe users;
+-------------------+---------------------+------+-----+---------+----------------+
| Field             | Type                | Null | Key | Default | Extra          |
+-------------------+---------------------+------+-----+---------+----------------+
| id                | bigint(20) unsigned | NO   | PRI | NULL    | auto_increment |
| name              | varchar(255)        | NO   |     | NULL    |                |
| email             | varchar(255)        | NO   | UNI | NULL    |                |
| email_verified_at | timestamp           | YES  |     | NULL    |                |
| password          | varchar(255)        | NO   |     | NULL    |                |
| remember_token    | varchar(100)        | YES  |     | NULL    |                |
| created_at        | timestamp           | YES  |     | NULL    |                |
| updated_at        | timestamp           | YES  |     | NULL    |                |
+-------------------+---------------------+------+-----+---------+----------------+

そして、EloquentのモデルのUserでは、以下のように$fillableが定義されています。

app/User.php

namespace App;

use Illuminate\Notifications\Notifiable;
use Illuminate\Contracts\Auth\MustVerifyEmail;
use Illuminate\Foundation\Auth\User as Authenticatable;

class User extends Authenticatable
{
    use Notifiable;

    /**
     * The attributes that are mass assignable.
     *
     * @var array
     */
    protected $fillable = [
        'name', 'email', 'password',
    ];

    /**
     * The attributes that should be hidden for arrays.
     *
     * @var array
     */
    protected $hidden = [
        'password', 'remember_token',
    ];

    /**
     * The attributes that should be cast to native types.
     *
     * @var array
     */
    protected $casts = [
        'email_verified_at' => 'datetime',
    ];
}

つまり、name, email, password以外の項目、例えば、idとかとともにマスアサインしても、以下のようにUserのインスタンスの作成時には弾かれる、ということです。

$ php artisan tinker
>>> $input = ['id' => 1, 'name' => 'test', 'email' => 'test@example.com'];
=> [
     "id" => 1,
     "name" => "test",
     "email" => "test@example.com",
   ]
>>> new User($input);
[!] Aliasing 'User' to 'App\User' for this Tinker session.
=> App\User {#2985
     name: "test",
     email: "test@example.com",
   }
>>>

作成されたインスタンスにおいては、idの項目はありません。fill()を使用しても同じことです。

>>> $user = new User();
=> App\User {#2984}
>>> $user->fill($input);
=> App\User {#2984
     name: "test",
     email: "test@example.com",
   }
>>>

そして、$fillableでなく、$guardedを使用しても結果は同じことです。

...
    // protected $fillable = [
    //     'name', 'email', 'password',
    // ];

    protected $guarded = [
        'id', 'email_verified_at', 'remember_token', 'created_at', 'updated_at'
    ];
...

保護を外す

さて、上の$fillableの保護指定をそのままにして、同じUserのモデルでidなど、name, email, password以外の項目を指定してインスタンスを作成したいときは、どうするのでしょう？

そこで登場するのが、unguard()のメソッドです。

>>> User::unguard()
=> null
>>> new User($input);
=> App\User {#2985
     id: 1,
     name: "test",
     email: "test@example.com",
   }
>>> $user = new User();
=> App\User {#2986}
>>> $user->fill($input);
=> App\User {#2986
     id: 1,
     name: "test",
     email: "test@example.com",
   }

idが入るようになりましたね。

解除するには、unguard(false)です。

>>> User::unguard(false);
=> null
>>> new User($input);
=> App\User {#2987
     name: "test",
     email: "test@example.com",
   }
>>>

以前のようにもうidは入りません。

unguard()はセッションで有効ですが、１つのインスタンスで保護を外すには、forceFill()を使用できます。

>>> $user = new User();
=> App\User {#2985}
>>> $user->forceFill($input);
=> App\User {#2985
     id: 1,
     name: "test",
     email: "test@example.com",
   }

fresh() vs refresh()

Sat, 31 Aug 2019 03:40:54 +0900

tinkerを使用して開発中の関数をいろいろ試験します。Eloquent関連の関数で複数のDBテーブルに渡り値を更新する関数ゆえに、tinkerがとても役に立つのです。しかし、試験中に不思議なことが起こりました。ちょっと格闘して、なるほどそこではこうすればいいのだな、という話を共有です。

まず、説明のためにhasManyのフェイクデータの作成のポストで環境を作成します。

以前のレコードが残っているかもしれないので、truncate()を実行して空にします。そこでfactory()を実行して、Userのレコードを１つ、Addressのレコードを２つ作成します。$user->addressesは、Userのモデルのrelationshipです。

$ php artisan tinker
sy Shell v0.9.9 (PHP 7.2.16 — cli) by Justin Hileman
>>> use App\User;
>>> use App\Address;
>>> User::truncate();
>>> Address::truncate();
=> Illuminate\Database\Eloquent\Builder {#2974}
>>> factory(App\User::class)->create()->each(function ($user) { $user->addresses()->saveMany(factory(App\Address::class, 2)->make()); });
=> true
>>> $user = User::find(1);
=> App\User {#2976
     id: 1,
     name: "三宅 桃子",
     email: "kaori01@example.org",
     email_verified_at: "2019-08-29 20:45:31",
     created_at: "2019-08-13 07:57:01",
     updated_at: "2019-08-13 07:57:01",
   }
>>> $user->addresses;
=> Illuminate\Database\Eloquent\Collection {#2986
     all: [
       App\Address {#2982
         id: 1,
         user_id: 1,
         address: "8427481  東京都松本市西区山田町廣川6-3-5 ハイツ喜嶋108号",
         created_at: "2019-08-29 20:45:31",
         updated_at: "2019-08-29 20:45:31",
       },
       App\Address {#2974
         id: 2,
         user_id: 1,
         address: "9979251  茨城県加藤市北区原田町山口7-7-5",
         created_at: "2019-08-29 20:45:31",
         updated_at: "2019-08-29 20:45:31",
       },
     ],
   }

さて、ここで$userの名前を変更してみます。

>>> $user->name = 'TEST';
=> "TEST"
>>> $user
=> App\User {#2976
     id: 1,
     name: "TEST",
     email: "kaori01@example.org",
     email_verified_at: "2019-08-29 20:45:31",
     created_at: "2019-08-13 07:57:01",
     updated_at: "2019-08-13 07:57:01",
     addresses: Illuminate\Database\Eloquent\Collection {#2986
       all: [
         App\Address {#2982
           id: 1,
           user_id: 1,
           address: "8427481  東京都松本市西区山田町廣川6-3-5 ハイツ喜嶋108号",
           created_at: "2019-08-29 20:45:31",
           updated_at: "2019-08-29 20:45:31",
         },
         App\Address {#2974
           id: 2,
           user_id: 1,
           address: "9979251  茨城県加藤市北区原田町山口7-7-5",
           created_at: "2019-08-29 20:45:31",
           updated_at: "2019-08-29 20:45:31",
         },
       ],
     },
   }

変わりましたね。しかし、まだ$user->save()を実行していないので、単に$userのインスタンスの値が変わっただけです。これをリセットするには、fresh()を使用します。

>>> $user->fresh();
=> App\User {#2979
     id: 1,
     name: "三宅 桃子",
     email: "kaori01@example.org",
     email_verified_at: "2019-08-29 20:45:31",
     created_at: "2019-08-13 07:57:01",
     updated_at: "2019-08-13 07:57:01",
   }
>>>

戻りましたね。しかし、$user自体は戻っていません。

>>> $user
=> App\User {#2976
     id: 1,
     name: "TEST",
     email: "kaori01@example.org",
     email_verified_at: "2019-08-29 20:45:31",
     created_at: "2019-08-13 07:57:01",
     updated_at: "2019-08-13 07:57:01",
     addresses: Illuminate\Database\Eloquent\Collection {#2986
       all: [
         App\Address {#2982
           id: 1,
           user_id: 1,
           address: "8427481  東京都松本市西区山田町廣川6-3-5 ハイツ喜嶋108号",
           created_at: "2019-08-29 20:45:31",
           updated_at: "2019-08-29 20:45:31",
         },
         App\Address {#2974
           id: 2,
           user_id: 1,
           address: "9979251  茨城県加藤市北区原田町山口7-7-5",
           created_at: "2019-08-29 20:45:31",
           updated_at: "2019-08-29 20:45:31",
         },
       ],
     },
   }

不思議ですね。

APIのマニュアルを見てみましょう。 https://laravel.com/api/5.8/Illuminate/Database/Eloquent/Model.html#method_fresh

そこの説明では、

Reload a fresh model instance from the database.

DBから新しいインスタンスをリロード、とありますが、元のインスタンスをリセットするのではなく、新しいインスタンスを作成して返しているようです。

つまり、元のインスタンスのリセットには、

>>> $user = $user->fresh();
=> App\User {#2979
     id: 1,
     name: "三宅 桃子",
     email: "kaori01@example.org",
     email_verified_at: "2019-08-29 20:45:31",
     created_at: "2019-08-13 07:57:01",
     updated_at: "2019-08-13 07:57:01",
   }
>>> $user
=> App\User {#2979
     id: 1,
     name: "三宅 桃子",
     email: "kaori01@example.org",
     email_verified_at: "2019-08-29 20:45:31",
     created_at: "2019-08-13 07:57:01",
     updated_at: "2019-08-13 07:57:01",
   }

と元のインスタンスに割り当てが必要となります。面倒ですね。fresh()は違う使用ケースがあるのでしょうか。と思っていたら、そのためにもう１つのメソッドrefersh()がありました。

>>> $user->name = 'TEST';
=> "TEST"
>>> $user;
=> App\User {#2979
     id: 1,
     name: "TEST",
     email: "kaori01@example.org",
     email_verified_at: "2019-08-29 20:45:31",
     created_at: "2019-08-13 07:57:01",
     updated_at: "2019-08-13 07:57:01",
   }
>>> $user->refresh();
=> App\User {#2979
     id: 1,
     name: "三宅 桃子",
     email: "kaori01@example.org",
     email_verified_at: "2019-08-29 20:45:31",
     created_at: "2019-08-13 07:57:01",
     updated_at: "2019-08-13 07:57:01",
   }
>>> $user
=> App\User {#2979
     id: 1,
     name: "三宅 桃子",
     email: "kaori01@example.org",
     email_verified_at: "2019-08-29 20:45:31",
     created_at: "2019-08-13 07:57:01",
     updated_at: "2019-08-13 07:57:01",
   }
>>>

一件落着です。このrefresh()のメソッド、関連しているレコードの反映にも役立つことわかりました。

例えば、

>>> $user->addresses;
=> Illuminate\Database\Eloquent\Collection {#2986
     all: [
       App\Address {#2982
         id: 1,
         user_id: 1,
         address: "8427481  東京都松本市西区山田町廣川6-3-5 ハイツ喜嶋108号",
         created_at: "2019-08-29 20:45:31",
         updated_at: "2019-08-29 20:45:31",
       },
       App\Address {#2974
         id: 2,
         user_id: 1,
         address: "9979251  茨城県加藤市北区原田町山口7-7-5",
         created_at: "2019-08-29 20:45:31",
         updated_at: "2019-08-29 20:45:31",
       },
     ],
   }

のように、ユーザーには２つの住所があります。ここの１つを更新してみます。

>>> $address = Address::find(1);
=> App\Address {#3015
     id: 1,
     user_id: 1,
     address: "8427481  東京都松本市西区山田町廣川6-3-5 ハイツ喜嶋108号",
     created_at: "2019-08-29 20:45:31",
     updated_at: "2019-08-29 21:16:30",
   }
>>> $address->update(['address' => 'TEST ADDRESS']);
=> true

しかし、以下を実行すると、

>>> $user->addresses
=> Illuminate\Database\Eloquent\Collection {#2971
     all: [
       App\Address {#2970
         id: 1,
         user_id: 1,
         address: "8427481  東京都松本市西区山田町廣川6-3-5 ハイツ喜嶋108号",
         created_at: "2019-08-29 20:45:31",
         updated_at: "2019-08-29 20:45:31",
       },
       App\Address {#2981
         id: 2,
         user_id: 1,
         address: "9979251  茨城県加藤市北区原田町山口7-7-5",
         created_at: "2019-08-29 20:45:31",
         updated_at: "2019-08-29 20:45:31",
       },
     ],
   }

最初のアドレスのレコードは、オリジナルのままですね。

そこで、refersh()を使いましょう。

>>> $user->refresh();
=> App\User {#2979
     id: 1,
     name: "三宅 桃子",
     email: "kaori01@example.org",
     email_verified_at: "2019-08-29 20:45:31",
     created_at: "2019-08-13 07:57:01",
     updated_at: "2019-08-13 07:57:01",
     addresses: Illuminate\Database\Eloquent\Collection {#3022
       all: [
         App\Address {#3020
           id: 1,
           user_id: 1,
           address: "TEST ADDRESS",
           created_at: "2019-08-29 20:45:31",
           updated_at: "2019-08-29 21:17:12",
         },
         App\Address {#3023
           id: 2,
           user_id: 1,
           address: "9979251  茨城県加藤市北区原田町山口7-7-5",
           created_at: "2019-08-29 20:45:31",
           updated_at: "2019-08-29 20:45:31",
         },
       ],
     },
   }

変更が反映されましたね。しかし、fresh()はいったいどういうときに使用するのでしょうかね。

isDirty() vs wasChanged()

Fri, 05 Jul 2019 01:07:02 +0900

このブログの一番最初に書いた記事において、isDirty()に関して書きました。もう4年くらい前のことです。最近必要になって使用したところ、新たな発見がありました。

更新あります！

まず、tinkerを使用して、isDirty()の復習です。 factory()を使って、１つレコードを作成します。

>>> factory(App\User::class)->create();
=> App\User {#2987
     name: "小林 春香",
     email: "kana.yamamoto@example.org",
     email_verified_at: "2019-07-02 03:01:25",
     updated_at: "2019-07-02 03:01:25",
     created_at: "2019-07-02 03:01:25",
     id: 1,
   }

作成したレコードの名前を更新しますが、DBでなくオブジェクトのみの更新のために、fill()を使用します。

>>> $user = User::find(1);
=> App\User {#2950
     id: 1,
     name: "小林 春香",
     email: "kana.yamamoto@example.org",
     email_verified_at: "2019-07-02 03:01:25",
     created_at: "2019-07-02 03:01:25",
     updated_at: "2019-07-02 03:01:25",
   }
>>> $user->fill(['name' => '山田花子']);
=> App\User {#2950
     id: 1,
     name: "山田花子",
     email: "kana.yamamoto@example.org",
     email_verified_at: "2019-07-02 03:01:25",
     created_at: "2019-07-02 03:01:25",
     updated_at: "2019-07-02 03:01:25",
   }

nameが変わりましたね。実際、オブジェクトが更新したかどうかは、isDirty()を使います。

>>> $user->isDirty();
=> true

変更していますね。項目ごとはどうでしょう？

>>> $user->isDirty('name');
=> true
>>> $user->isDirty('email');
=> false

nameの変更がありますが、emailの変更はなしです。正しいです。

ここで、変更したオブジェクトをもとに対応するレコードをDBに保存します。

>>> $user->save();
=> true

さて、この時点でのisDirty()の返り値は？

>>> $user->isDirty();
=> false
>>> $user->isDirty('name');
=> false

もう、isDirty()では、変更があったかどうかの判断はできません、何もDirtyではありません。

>>> $user->wasChanged();
=> true
>>> $user->wasChanged('name');
=> true
>>> $user->wasChanged('email');
=> false

save()前のisDirty()の結果とまったく同じです。

実際には、こんなコードでwasChanged()は使われます。

...
$user->fill(['name' => '山田花子']);

if ($user->isDirty()) {
    $user->save();
    if ($user->wasChagned('name')) {
        //nameが更新されたときのみ、以下のコードを実行
        ...
    }
}
...

こういうときにwhereRawを使う

Sat, 09 Mar 2019 06:37:58 +0900

これも、前回と同様「実はそうでなかった」のトピックです。今度は、Eloquentのクエリーにおいてwhere()で条件を指定するとき。

早速、tinkerを使って具体的な例を作成します。

Psy Shell v0.9.3 (PHP 7.1.14 — cli) by Justin Hileman
>>>  factory(App\User::class,2)->create()
=> Illuminate\Database\Eloquent\Collection {#2341
     all: [
       App\User {#2337
         name: "笹田 洋介",
         email: "jun91@example.com",
         updated_at: "2019-03-08 08:24:36",
         created_at: "2019-03-08 08:24:36",
         id: 1,
       },
       App\User {#2333
         name: "高橋 舞",
         email: "hideki31@example.com",
         updated_at: "2019-03-08 08:24:36",
         created_at: "2019-03-08 08:24:36",
         id: 2,
       },
     ],
   }

factory()を使用して、２つレコードをusersのテーブルに作成しました。これら、もちろんですが作成したばかりなので、作成時間と更新時間はどちらのレコードも同じ、つまりcreated_at == updated_at　です。

ということは、where()でその条件を指定してやれば、両方のレコードとも取得できますよね。早速クエリを実行してみます。

>>> User::where('created_at', '=', 'updated_at')->get();
=> Illuminate\Database\Eloquent\Collection {#2340
     all: [],
   }

あれれ、結果は空ですね。この前作成した、tinkerのsql()で実行されたSQL文を見てみると、

>>> sql()
=> [
...
     [
       "query" => "select * from `users` where `created_at` = ?",
       "bindings" => [
         "updated_at",
       ],
       "time" => 3.5,
     ],
   ]

そう、usersテーブルの項目を指定しているのでなく、文字列の“updated_at”の指定となっているのです。どうりで空の取得となるわけです。

正しくは、

>>> User::whereRaw('created_at = updated_at')->get();
=> Illuminate\Database\Eloquent\Collection {#2345
     all: [
       App\User {#2332
         id: 1,
         name: "笹田 洋介",
         email: "jun91@example.com",
         created_at: "2019-03-08 08:24:36",
         updated_at: "2019-03-08 08:24:36",
       },
       App\User {#2339
         id: 2,
         name: "高橋 舞",
         email: "hideki31@example.com",
         created_at: "2019-03-08 08:24:36",
         updated_at: "2019-03-08 08:24:36",
       },
     ],
   }

と、whereRaw()を使用して、生の条件文を入れてやるのです。実行されたSQL文を見てみると、

>>> sql()
=> [
...
     [
       "query" => "select * from `users` where created_at = updated_at",
       "bindings" => [],
       "time" => 0.8,
     ],
   ]

と正しいSQL文となっています。

正しいのは、isEmptyでした

Sat, 02 Mar 2019 03:57:47 +0900

日常、いつもの考えや習慣で仮定してしまい、「実はそうでなかった」と後で冷や汗なること多々あります。Laravelのプログラミングもそうです。その過ちを繰り返さないために、出会ったらブログに書いていくことにします。

今回はCollectionに関して、最近うっかりしたこと。

例えば、tinkerで空の結果のEloquentのCollectionを作成して、

>>> $users = User::where('email', '=', '')->get(); // 空のCollection

=> Illuminate\Database\Eloquent\Collection {#2319
     all: [],
   } 

>>> if (empty($users)) echo "空です！"

empty()で空の判断を試みるが、「実はそうでなかった」。 empty()は引数が配列ならＯＫだけれど、Collectionのオブジェクトなら空を判断できません。

正しくは、Collectionのメソッド、isEmpty()を使います。

>>> if ($users->isEmpty()) echo "空です！"

空です！

同様に、count()でレコード数を数えてもＯＫですが、否定の!が必要。

>>> if (!$users->count()) echo "空です！"

空です！

また、配列を取り出すなら、empty()も使えます。

>>> if (empty($users->all())) echo "空です！"

空です！

tinkerのブートストラップファイル

Fri, 22 Feb 2019 23:44:13 +0900

先日、tinkerに関して私が知らなかった機能を見つけました。tinkerを好んで日夜使用する私としては、これは作業効率が上がるわ、とわくわくする機能です。

tinkerで私がよく使うのは、以下のようなEloquentの関数で実行される裏側のSQL文の表示です。

Psy Shell v0.9.3 (PHP 7.1.14 — cli) by Justin Hileman
>>> DB::enableQueryLog()
=> null
>>> User::find(1)
[!] Aliasing 'User' to 'App\User' for this Tinker session.
=> App\User {#2316
     id: 1,
     name: "江古田 明美",
     email: "kazuya24@example.net",
     created_at: "2019-01-18 14:02:42",
     updated_at: "2019-01-18 14:02:42",
   }
>>> DB::getQueryLog()
=> [
     [
       "query" => "select * from `users` where `users`.`id` = ? limit 1",
       "bindings" => [
         1,
       ],
       "time" => 8.01,
     ],
   ]
>>>

この例ではシンプルなSQL文ですが、これがhasManyThroughとかbelongsToManyだとかの複雑なリレーションになると、joinの接続が本当にこちらの期待通りなのか、などのチェックしたくなります。しかし、 DB::enableQueryLog()やDB::getQueryLog()を覚えるのも大変であるし、毎回毎回それをタイプするのも面倒！

なんか簡単にエイリアスみたいなことができないかと、探していてわかったのが、tinkerのブートストラップファイル。

まず、以下の内容のPHPファイルを作成します。

start.php

<?php
DB::enableQueryLog();

function sql() {
   return DB::getQueryLog();
}

そして、そのファイル名を引数として、tinkerを実行します。

$ php artisan tinker start.php
[bash]
Psy Shell v0.9.3 (PHP 7.1.14 — cli) by Justin Hileman
>>> User::find(1)
[!] Aliasing 'User' to 'App\User' for this Tinker session.
=> App\User {#2316
     id: 1,
     name: "江古田 明美",
     email: "kazuya24@example.net",
     created_at: "2019-01-18 14:02:42",
     updated_at: "2019-01-18 14:02:42",
   }
>>> sql()
=> [
     [
       "query" => "select * from `users` where `users`.`id` = ? limit 1",
       "bindings" => [
         1,
       ],
       "time" => 8.01,
     ],
   ]
>>>

そう、start.phpはすでにtinker内で先に実行されるので、SQLのログ機能はすでにオンとなっているし、SQL文を見たいときは、sql()とだけタイプすればいいのです。これなら忘れませんね。

hasManyのフェイクデータの作成

Sun, 13 Jan 2019 02:19:08 +0900

hasManyリレーションは、Eloquentのモデル間（つまり、DBのテーブル間）に1対多の関係を持たせるリレーションです。今回は、factory()を使って、このhasManyのリレーションを持つDBテーブルにフェイクデータを作成してみます。

hasMany

DBにおける1対多の関係では、2つのDBテーブルを親子とみなすと、親の１レコードに対してそれに紐づく子のレコードが１あるいは複数存在します。

例えば、親をusers（ユーザー）、子をaddresses（住所）とし、それぞれのEloquentのモデル、User、Addressを定義し、User::addresses()のリレーションを定義すれば、以下のようなデータとなります。

>>> User::find(1)->load('addresses');
=> App\User {#2312
     id: 1,
     name: "原田 涼平",
     email: "esasada@example.com",
     created_at: "2019-01-12 01:53:58",
     updated_at: "2019-01-12 01:53:58",
     addresses: Illuminate\Database\Eloquent\Collection {#2340
       all: [
         App\Address {#2349
           id: 1,
           user_id: 1,
           address: "8731301  山口県石田市中央区田中町高橋1-5-6 コーポ高橋110号",
           created_at: "2019-01-12 01:53:58",
           updated_at: "2019-01-12 01:53:58",
         },
         App\Address {#2348
           id: 2,
           user_id: 1,
           address: "7159410  京都府坂本市北区加納町加藤9-7-8",
           created_at: "2019-01-12 01:53:58",
           updated_at: "2019-01-12 01:53:58",
         },
       ],
     },
   }

ここでは、原田さんは２つの住所を持つことが表示されています。もちろん、これらはフェイクデータですが、次の準備をすればこれがtinkerの１行の実行で親子のレコードを作成できます。

準備

Laravelの新規のプロジェクトを作成すると、usersのmigration、model、factoryがすでに定義されています。ここで必要なのは、addressesにおいて同様な定義です。

まず、migrationから

$ php artisan make:migration create_addresses_table --create=addresses

上のコマンドラインでの実行で、

$ ls -1 database/migrations 
2014_10_12_000000_create_users_table.php
2014_10_12_100000_create_password_resets_table.php
2019_01_10_140631_create_addresses_table.php

2019_01_10_140631_create_addresses_table.phpのファイルが作成されます。これを以下のように編集。

use Illuminate\Support\Facades\Schema;
use Illuminate\Database\Schema\Blueprint;
use Illuminate\Database\Migrations\Migration;

class CreateAddressesTable extends Migration
{
    /**
     * Run the migrations.
     *
     * @return void
     */
    public function up()
    {
        Schema::create('addresses', function (Blueprint $table) {
            $table->increments('id');
            $table->integer('user_id')->unsigned();
            $table->string('address');
            $table->timestamps();
        });
    }

    /**
     * Reverse the migrations.
     *
     * @return void
     */
    public function down()
    {
        Schema::dropIfExists('addresses');
    }
}

users.idと紐づけるために、addresses.user_idの項目が追加されていることに注意してください。

そして、次を実行して、addressesのDBテーブルを作成します。

$ php artisan migrate
Migrating: 2019_01_10_140631_create_addresses_table
Migrated:  2019_01_10_140631_create_addresses_table

次に、モデルを作成。これもコマンドラインで実行。

$ php artian make:model Address

以下のファイルが作成されます。

app/Address.php

そしてこれを以下のように編集。

namespace App;

use Illuminate\Database\Eloquent\Model;

class Address extends Model
{
    protected $fillable = [
        'address'
    ];
}

Addressのモデルができたところで、UserのモデルにhasManyのリレーション、addresses()を定義します。

app/User.php

namespace App;

use Illuminate\Notifications\Notifiable;
use Illuminate\Foundation\Auth\User as Authenticatable;
use App\Auth\Passwords\CanResetPassword;

class User extends Authenticatable
{
    use Notifiable;
	use CanResetPassword;

    /**
     * The attributes that are mass assignable.
     *
     * @var array
     */
    protected $fillable = [
        'name', 'email', 'password',
    ];

    /**
     * The attributes that should be hidden for arrays.
     *
     * @var array
     */
    protected $hidden = [
        'password', 'remember_token',
    ];

    public function addresses()
    {
        return $this->hasMany('App\Address');
    }
}

そして、Addressのフェイクデータを作成するためにfactoryを作成します。

$ php artisan make:factory AddressFactory

この実行でAddressFactory.phpのファイルが作成されます。

$ ls -1 database/factories 
AddressFactory.php
UserFactory.php

これを以下のように編集。

use Faker\Generator as Faker;                                                                                                                                                                                      
                                                                                                                                                                                                                   
$factory->define(App\Address::class, function (Faker $faker) {                                                                                                                                                     
    return [                                                                                                                                                                                                       
       'address' => $faker->address                                                                                                                                                                                
    ];                                                                                                                                                                                                             
});

最後に、フェイクデータを日本語で作成するために、config/app.phpに以下を追加します。

..
    'faker_locale' => 'ja_JP', 
..

これで準備終わり。

フェイクデータの作成

さて、tinkerの出番です。

$ php artisan tinker

>>> factory(App\User::class)->create()->each(function ($user) { $user->addresses()->save(factory(App\Address::class)->make()); });
=> true
>>> User::find(1)->load('addresses');
=> App\User {#2310
     id: 1,
     name: "近藤 亮介",
     email: "mikako.koizumi@example.net",
     created_at: "2019-01-12 02:56:16",
     updated_at: "2019-01-12 02:56:16",
     addresses: Illuminate\Database\Eloquent\Collection {#2347
       all: [
         App\Address {#2349
           id: 1,
           user_id: 1,
           address: "8657778  滋賀県松本市南区中島町笹田9-6-2",
           created_at: "2019-01-12 02:56:16",
           updated_at: "2019-01-12 02:56:16",
         },
       ],
     },
   }

factoryの実行文が長いので、整形して表示してみましょう。

factory(App\User::class)->create()
    ->each(function ($user) {
        $user->addresses()
            ->save(
               factory(App\Address::class)->make()
　　　　     ); 
    });

1行目で、usersのレコードが作成され、それぞれのusersのレコードにおいて、addresses()のリレーションをもとにaddressesのレコードが作成されます。

１つのusersのレコードに対して、addressesのレコードが複数欲しいなら、save()の部分を

saveMany(factory(App\Address::class, 2)

に置き換えます。以下のように２つaddressesのレコード作成となります。

>>> factory(App\User::class)->create()->each(function ($user) { $user->addresses()->saveMany(factory(App\Address::class, 2)->make()); });
=> true
>>> User::find(2)->load('addresses');
=> App\User {#2368
     id: 2,
     name: "津田 七夏",
     email: "kudo.kaori@example.org",
     created_at: "2019-01-12 02:59:24",
     updated_at: "2019-01-12 02:59:24",
     addresses: Illuminate\Database\Eloquent\Collection {#2369
       all: [
         App\Address {#2354
           id: 4,
           user_id: 2,
           address: "8621292  長崎県石田市中央区大垣町渡辺3-6-8",
           created_at: "2019-01-12 02:59:24",
           updated_at: "2019-01-12 02:59:24",
         },
         App\Address {#2357
           id: 5,
           user_id: 2,
           address: "6857809  沖縄県三宅市南区山本町山岸9-5-9 コーポ山口101号",
           created_at: "2019-01-12 02:59:24",
           updated_at: "2019-01-12 02:59:24",
         },
       ],
     },
   }

DBレコードのコピー

Sun, 06 Jan 2019 05:34:12 +0900

レコードのコピーという作業は結構起こることです。例えば、Eコーマースのサイトなら、サイズだけが違う商品は、説明などの他の属性はほとんど同じなので、わざわざ新規の商品の情報をすべて手入力というよりは、既存の商品をもとに編集する方がもちろん簡単です。

さて、このレコードのコピー作業、Eloquentではどうやるのでしょう？

tinkerを立ち上げます。

まず、usersのテーブルを空にしましょう。

Psy Shell v0.9.9 (PHP 7.1.14 — cli) by Justin Hileman
>>> User::truncate();
=> Illuminate\Database\Eloquent\Builder {#2862}
>>> User::count();
=> 0

次に、ファクトリーを利用してレコードを１つ作成します。

>>> factory(App\User::class, 1)->create();
=> Illuminate\Database\Eloquent\Collection {#2896
     all: [
       App\User {#2892
         name: "Yessenia Jast",
         email: "modesto24@example.org",
         updated_at: "2019-01-06 05:13:54",
         created_at: "2019-01-06 05:13:54",
         id: 1,
       },
     ],
   }
>>>

そして、このレコードをcloneして保存。

>>> $user = User::find(1);
=> App\User {#121
     id: 1,
     name: "Yessenia Jast",
     email: "modesto24@example.org",
     created_at: "2019-01-06 05:13:54",
     updated_at: "2019-01-06 05:13:54",
   }
>>> $clone = clone $user;
=> App\User {#2894
     id: 1,
     name: "Yessenia Jast",
     email: "modesto24@example.org",
     created_at: "2019-01-06 05:13:54",
     updated_at: "2019-01-06 05:13:54",
   }
>>> $clone->save();
=> true
>>> User::count();
=> 1
>>>

あれれ、新規のレコードを作成してくれませんね。レコード数はオリジナルのレコードの1個です。$cloneは単に同じDBレコードを違うオブジェクトとしただけなので、$clone->save()は新規登録ではなく既存のレコードの編集となってしまうようです。

正しいやり方は、Eloquentのreplicate()を使用してコピーのオブジェクトを作成します。

>>> $clone = $user->replicate();
=> App\User {#2862
     name: "Yessenia Jast",
     email: "modesto24@example.org",
   }
>>> $clone->email = 'test@example.com';
=> "test@example.com"
>>> $clone->save();
=> true

emailはユニークな値でないとDBの重複エラーとなるので違う値にしてsaveしていることに注意してください。

以下のように、レコードは２つになり、複製が作成されています。

>>> User::all();
=> Illuminate\Database\Eloquent\Collection {#2863
     all: [
       App\User {#2888
         id: 1,
         name: "Yessenia Jast",
         email: "modesto24@example.org",
         created_at: "2019-01-06 05:13:54",
         updated_at: "2019-01-06 05:13:54",
       },
       App\User {#2893
         id: 2,
         name: "Yessenia Jast",
         email: "test@example.com",
         created_at: "2019-01-06 05:16:06",
         updated_at: "2019-01-06 05:16:06",
       },
     ],
   }

チャンキングは遅い

Mon, 29 Oct 2018 01:52:51 +0900

前回は、チャンキングでプログラムが使用するメモリの量を抑えることを説明しましたが、実行速度はどうなのでしょう？

私の仮想マシンで測定してみました。50万のレコードがあります。

1000レコードごとのチャンキングは、1分32秒。

チャンキングなしで、メモリ制限を1ギガバイトとして、46秒。

チャンキングの方が2倍以上時間かかっています。

チャンキングがどのようなSQLのクエリを実行するか、tinkerで見てみます。数が多いので、ここでは10,000レコードごとのチャンキングにしています。

>>> DB::enableQueryLog();
=> null
>>> DB::table('users')->count();
=> 500000
>>> App\User::chunk(10000, function($rows) { });
=> true
>>> DB::getQueryLog();
=> [
     [
       "query" => "select count(*) as aggregate from `users`",
       "bindings" => [],
       "time" => 152.78,
     ],
     [
       "query" => "select * from `users` order by `users`.`id` asc limit 10000 offset 0",
       "bindings" => [],
       "time" => 76.14,
     ],
     [
       "query" => "select * from `users` order by `users`.`id` asc limit 10000 offset 10000",
       "bindings" => [],
       "time" => 59.68,
     ],
... 途中はスキップ
     [
       "query" => "select * from `users` order by `users`.`id` asc limit 10000 offset 480000",
       "bindings" => [],
       "time" => 246.93,
     ],
     [
       "query" => "select * from `users` order by `users`.`id` asc limit 10000 offset 490000",
       "bindings" => [],
       "time" => 227.26,
     ],
     [
       "query" => "select * from `users` order by `users`.`id` asc limit 10000 offset 500000",
       "bindings" => [],
       "time" => 191.65,
     ],
   ]

チャンキングでは、limit 10000 offset 0のように、開始するレコードの場所と取得する数をクエリで指定しています。開始するレコードの場所がここでは10,000ごと増えていきます。そして、そのためにクエリの実行がだんだん遅くなっていきます。遅さは加速されているようで、最後の方では最初の5倍くらい時間がかかっています。

レコード数が5百万あるテーブルの実験では、1000のチャンキングでは百万程度から非常に遅くなっていき、何時間たっても終わらず、いつまでも終わらないのではないか、くらいのスピードになりました。

メモリの使用は控えてくれるけれど、レコード数が多い（とても多い）ときの処理時間が途方もなく長くなります。

どう解決したらよいかと考えて、思いついたのが以下の方法です。まずコードを見てください。

...
        $max = User::max('id');
        $unit = 1000;

        for ($i = 0; $i < intval(ceil($max/$unit)); $i++) {
            $from = $i * $unit + 1;
            $to = ($i + 1) * $unit;

            $rows = User::where('id', '>=', $from)
                ->where('id', '<=', $to)
                ->get();

            foreach ($rows as $row) {
                $values = [
                    $row->id,
                    $row->created_at,
                    $row->name,
                    $row->email
                ];
 
                fputcsv($fh, $values);
           }
       }
...

チャンキングと似ていますが、limit, offsetを使用するのではなく、idの値の1000ごとの範囲を指定してループします。idはDBテーブルのプライマリーキーゆえにスピード向上される、という仮定です。

測定してみました。処理時間は予想通り縮まり45秒となりました。チャンキングなしとほぼ同じです。しかも使用メモリは抑えられて。

レコード数だけでなく対象のDBテーブルのサイズなどとも関係があると思いますが、同じような状況に至ったときには試してみてください。

チャンキングで使用メモリを抑える

Sun, 21 Oct 2018 04:50:49 +0900

データベースの含まれるレコード数が増えてくると今まで経験しなかったことを経験するようになります。

まず最初に出くわすのが、以下のようなコマンドラインでのコマンド実行のエラーです。

$ php artisan command:dump
HP Fatal error:  Allowed memory size of 134217728 bytes exhausted (tried to allocate 56000000 bytes) in /vol1/usr/www/larajapan/repos/larajapan/vendor/laravel/framework/src/Illuminate/Database/Connection.php on line 330

In Connection.php line 330:
                                                                                       
  Allowed memory size of 134217728 bytes exhausted (tried to allocate 56000000 bytes)

これは、実行しているプログラムのメモリの使用が現在設定しているphpのメモリ制限を超えようとしたよ、という親切なエラーです。確かに、php.iniで設定されているデフォルトの134217728バイト（128メガバイト）は小さ過ぎますね。

phpのプロセスのメモリ使用制限は、システム変数memory_limitで設定できるので、以下のように簡単に変更できます。 128メガバイトから倍の256メガバイトに増やします。

...
ini_set('memory_limit', 256M');
...

しかし、それでもエラーとなります。

PHP Fatal error:  Allowed memory size of 268435456 bytes exhausted (tried to allocate 2097152 bytes) in /vol1/usr/www/larajapan/repos/larajapan/vendor/laravel/framework/src/Illuminate/Database/Connection.php on line 332

In Connection.php line 332:
                                                                                      
  Allowed memory size of 268435456 bytes exhausted (tried to allocate 2097152 bytes)

もっと使用可能なメモリを増やすべき？

ここで、どんなプログラムを実行しているか見てみましょう。

app/Console/Commands/DumpCommand.php

namespace App\Console\Commands;

use Illuminate\Console\Command;

use App\User;

class DumpCommand extends Command
{
    /**
     * The name and signature of the console command.
     *
     * @var string
     */
    protected $signature = 'command:dump';

    /**
     * The console command description.
     *
     * @var string
     */
    protected $description = 'Dump data in csv format';

    /**
     * Create a new command instance.
     *
     * @return void
     */
    public function __construct()
    {
        parent::__construct();
    }

    /**
     * Execute the console command.
     *
     * @return mixed
     */
    public function handle()
    {
        ini_set('memory_limit', '256M');

        $fields  = [
            'id',
            'created_at',
            'name',
            'email'
        ];

        // CSV出力

        $fh = fopen('users.csv', 'w');

        fputs($fh, chr(0xEF).chr(0xBB).chr(0xBF));
        fputcsv($fh, $fields);

        $rows = User::all();

        foreach ($rows as $row) {
            $values = [
                $row->id,
                $row->created_at,
                $row->name,
                $row->email
            ];

            fputcsv($fh, $values);
        }

        fclose($fh);

        //ここに使用したメモリを表示
        printf("memory usage: %s\n",
            $this->formatBytes(memory_get_peak_usage(true)));

        return 0;
    }

    // バイトをメガバイトに変更
    public static function formatBytes($size, $precision = 0)
    {
        $base = log($size, 1024);
        $suffixes = array('', 'K', 'M', 'G', 'T');

        return round(pow(1024, $base - floor($base)), $precision) . $suffixes[floor($base)];
    }
}

このプログラムはＤＢテーブルのデータをすべてCSVのファイルにエクスポートするプログラムです。プログラムの最後に、どれだけメモリを使用したかを表示するようにしていますが、先の実行では、途中でエラーとなっためでそこまで到達していません。

さらにメモリを増やしてみましょう。今度は1ギガバイトまで増やして、つまりini_set(‘memory_limit’, ‘1G’)と設定して実行してみます。

memory usage: 804M

実行は成功です！そして、メモリがピーク時には804メガバイト使用されていることがわかりました。

昨今のマシンでは1ギガバイトくらいのメモリ使用はたいしたことありません。しかし、実行の前に途中でエラーにならないように、前もってどこまで増やせばよいのでしょう？

今回はテストのために、50万のレコードを用意しました。私のお客さんのＤＢではその10倍ものレコード数があるＤＢテーブルがあります。

ここで、もう一度プログラムを見てみます。このプログラムは、データベースのデータをCSVのファイルにエクスポートするプログラムですが、ファイルに書き込む前に、すべてのレコードを変数：$rowsにいったん入れています、つまりメモリの保存しているわけで、レコード数が多くなればなるほどメモリが必要となります。しかし、前もってどれだけメモリを使用するかの計算は難しいです。

もっとメモリの使用を低く抑えてマネージすることはできないのでしょうか？

そこで登場するのがEloquentのchunk()、これで上のプログラムのループ部分を以下のように書き変えます。

...
        User::chunk(1000, function($rows) use($fh) {
            foreach ($rows as $row) {
                $values = [
                    $row->id,
                    $row->created_at,
                    $row->name,
                    $row->email
                ];

                fputcsv($fh, $values);
            }
        });
...

最初からすべてのレコードを取ってくるのではなく、まず、レコードを1000個のチャンクで取ってきてクロージャの部分を実行し、そして次の1000個を取得して処理と。。それゆえに、$rowsに保存するデータは前回に比べてはるかに少なくなります。

これを実行すると、使用するメモリは驚くほど少なくなりました。

memory usage: 14M

Laravel 5.3 タイムスタンプのDB項目名の指定

Sat, 26 Nov 2016 10:12:28 +0900

Laravel 5.3に更新して、Eloquentのモデルの設定において嬉しいこと発見しました。

LaravelのEloquentでは、指定のDBテーブルにおいて、作成日時と編集日時に、規定のcreated_atとupdated_atの項目名が使用されているなら、いちいち、

use Users;
use Carbon\Carbon;

$user = new Users;
...
$user->created_at = $user->updated_at = Carbon::now();

$user->save();

というようなことを、DBレコードの追加や編集の際に、書かなくとも自動で作成日時と編集日時に値を入れてくれます。

私のケースでは、既存のプロジェクトのDBにおいて、作成日時と編集日時には、date_created、date_modifiedと違う名前を使用していて、今まで「いちいち」コードで指定していました。

しかし、Laravel 5.3では、以下のようにモデルの定数(const)を指定することで、項目名を指定できるようになりました。

namespace App\Models;

use Illuminate\Database\Eloquent\Model;

class Company extends Model
{
	protected $table = 'company';
	protected $primaryKey = 'company_id';
	public $timestamps = true; //デフォルトではtrueなので、指定する必要はない

	const CREATED_AT = 'date_created';
	const UPDATED_AT = 'date_modified';
..

これは大変便利です。

もう１つ便利なことで最近見つけたことは、最初の例で使用したCarbonは、Laravelをインストールしたら一緒にインストールされるパッケージですが、使い勝手あります。

例えば、DBに記録した日時から現在までの「経過日数」を計算するには、

$days_past = (new Carbon($user->updated_at))->diff(Carbon::now())->days;

簡単でわかりやすいですね。これをphpでやろうとすると、文字列から秒数に変換してなどと大変です。

最後に、日時の使用で忘れてならないのは、必ずアプリの設定ファイルで、タイムゾーンを設定すること。

config/app.php

..
    'timezone' => env('APP_TIMEZONE', 'Asia/Tokyo'),
..

入力のブラックリストとホワイトリスト

Sat, 03 Sep 2016 08:25:41 +0900

このブログを開始してから、もうすでに1年以上。RawのSQLを書いてコードに埋め込む日常から、Eloquentを使用したORMのコードへと日常へと移行しています。Eloquentに関しても、ブログを書き始めた頃からは理解が深まり、洗練されたLaravelのコードを書けるようになってきたこの頃です。

１年前に書いた「マスアサインメントで一括取り込み」のトピックで、EloquentのModelのクラスの属性fillableとguardedの話、1年の経験で学んだことを含めてここでもう一度説明します。

まず、話のお膳立てを。

DBテーブルmemberにおいて以下の項目があるとします。

+----------------+------------------+------+-----+---------------------+----------------+
| Field          | Type             | Null | Key | Default             | Extra          |
+----------------+------------------+------+-----+---------------------+----------------+
| member_id      | int(10) unsigned | NO   | PRI | NULL                | auto_increment |
| active_flag    | char(1)          | NO   |     | NULL                |                |
| name           | varchar(255)     | NO   |     | NULL                |                |
| email          | varchar(255)     | NO   | UNI | NULL                |                |
| password       | varchar(60)      | NO   |     | NULL                |                |
| memo           | varchar(100)     | YES  |     | NULL                |                |
| created_at     | timestamp        | NO   |     | 0000-00-00 00:00:00 |                |
| updated_at     | timestamp        | NO   |     | 0000-00-00 00:00:00 |                |
+----------------+------------------+------+-----+---------------------+----------------+

MemberのModelは以下のような定義になります。

Member.php

...
class Member extends Model
{
    protected $table = 'member';
    protected $primaryKey = 'member_id';
    protected $fillable = ['name', 'email'];
    ...
}

$timestampsや$incrementingの定義は必要ないです。両方ともデフォルトでtrueなので。

入力フォームは、

で、email, password, nameの項目を入力できます。

以下のコントローラで、入力フォームから入ってきた値は以下のコードでDBに保存できます。

MemberController.php

...
class MemberController extends Controller
{
    ...
    public store(Request $request)
    {
        $member = new Member;
        $member->fill($request->all())->save();
        ...
    }
    ...
}

しかし、先ほどの$fillable定義により、DBに保存されるのは、emailとnameのみです。実行されるSQLは以下で、他の入力された値は無視されるので、passwordはDBはデフォルトの空のままです。つまり、$fillableは、DBに入力したい値をリストするホワイトリストです。ちなみに、created_at, updated_atの項目は、Eloquentにより自動的に保存時の日時を記録します。

逆に、DBに入れたくない項目をリストするなら、つまりブラックリストを定義したいなら、$fillableの代わりに、$guardedを使用します。

Member.php

...
class Member extends Model
{
    protected $table = 'member';
    protected $primaryKey = 'member_id';
    protected $guarded = ['member_id', 'active_flag', 'password'];
    ...
}

以上がマスアサイメントの使用の仕方で、意図的あるいは間違って入力フォームから、DBへ保存されるのを防いでくれます。

$fillableや$guardedの目的を理解したところで、２つ問題。

まず、

active_flagやpasswordなどマスアサインメントで相手にしない項目の値はどうやってDBに保存するのでしょう？

これは、通常のオブジェクトの値のアサインメントで行います。

...
    public store(Request $request)
    {
        $member = new Member;
        $member->active_flag = 'Y'; //デフォルト
        $member->password = bcrypt($request->password);　//ハッシュ値に変換
        $member->fill($request->all())->save();
        ...
    }
...

次に、 入力画面によりDBに入れたい項目が違う場合は、どう$fillableを設定？

例えば、管理画面で会員の情報を編集する画面。そこでは、会員が有効か無効のフラッグ(active_flag)、そして会員に関するノート(memo)も付加情報としてDBに保存したいです。もちろん、裏で使用するのは、同じMemberのクラスなので、同じ$fillableは使えないですね。

１つは、先の値のアサイメント使用する方法。

    $member->active_flag = $request->active_flag;
    $member->memo = $request->memo;
    $member->fill($request->all())->save();

しかし、これではもっと項目が増えたら面倒です。

$fillableを使用するのではなく、先のように$guardedをMemberで定義して、以下のようにコントローラにおいて、独自の$fillableを使用します。

...
    public store(Request $request)
    {
　　　　 $fillable = ['email', 'name'];
        $input = array_only($request->all(), $fillable);
        $member = new Member;
        $member->active_flag = 'Y';
        $member->password = Hash::make($request->password);
        $member->fill($input)->save();
        ...
    }

    public edit(Member $member, Request $request)
    {
        $fillable = ['email', 'name', 'active_flag', 'memo'];
        $input = array_only($request->all(), $fillable);
        $member->fill($input)->save();
        ...
    }
...

array_onlyの関数は、Laravelのヘルパー関数です。

親子関係のテーブルでのクエリーの作成（Eloquent編）

Sat, 09 Jul 2016 09:52:13 +0900

Laravel以前は、ほぼコードにSQL文を埋め込んでいたので、Eloquentよりクエリビルダーの方が馴染みあります。特に複数のDBテーブルをjoinした検索などには。

しかし、各Modelにおいてリレーションを定義していると、それを使用しないのがもったいないように思えてきます。

クエリビルダーでできることをEloquentではどうやるのか、興味ありありになってきました。

前回と同じ検索、親子関係のテーブルをリレーションを使ってできるか考えてみましょう。

前回と同様に、商品productと商品画像product_imageの親子関係、つまり、１対多の関係があるとします。その関係をモデルで定義するには、以下。一応名前は、product_imagesと複数形にしてありますが、関数名のコンフリクトがないなら単数形でもOKです（要はプログラム内でどちらかに統一すること）。

Product.php

namespace App;

use Illuminate\Database\Eloquent\Model;

class Product extends Model
{
...
    public function product_images()
    {
        return $this->hasMany('App\ProductImage');
    }
}

Laravelのマニュアルによると、hasが親子のテーブルをjoinしてくれるようです。

$products = Product::has('product_images')->get();

この実行は以下のようなSQL文となります。

select * from `product` where exists (select * from `product_image` where `product_image`.`product_id` = `product`.`product_id`)

ちょっと通常のjoinとは違いますね。

しかし、商品画像のレコードを１つでも持つ商品は、これ使えそうですね。そうなら、検索値で絞るとすると、

$input = [
    'name' => '商品名',
    'mime' => 'image/gif'
];

$products = Product::has('product_images')
    ->where('name', $input['name'])
　　->where('mime', $input['mime'])
　　->get();

しかし、これを実行するとエラーとなります。なぜなら、whereは両方とも、Productに対しての条件となり、mimeの項目名が、productに存在しないというエラーとなります。

正しくやるには、前回のクエリビルダーで使用したwhereInのようなものが必要です。

$input = [
    'name' => '商品名',
    'mime' => 'image/gif'
];

$products = Product::where('name', $input['name'])
    ->whereHas('product_images', function($query) use($input) {
	$query->where('mime', $input['mime']);
})->get();

今回は、クエリビルダーと違って、whereInを使うではなく、whereHasとなります。また、whereHasゆえに、Product::hasは要らなくなります。ちょっと慣れが必要ですね。

これを実行すると、SQL文は以下のようになります。

select * from `product` where `name` = 'Produt' and exists (select * from `product_image` where `product_image`.`product_id` = `product`.`product_id` and `mime` = 'image/gif')

Eloquentでカウントするときの注意

Sun, 19 Jun 2016 03:56:11 +0900

Eloquentのcount()の関数を使用して、DBのレコード数を数える作業はよく起こります。

例えば、前回の画像の件では、商品productのレコード１に対して商品画像product_imageレコードが複数あるという、１対多の関係。そこでは、商品を削除するときに商品画像がないかをチェックする必要あります。画像のレコードがあるなら、削除を拒否あるいはユーザーに削除してよいか尋ねるということになります。

この場合は、商品画像があるかないかは、count()するのが一番。しかし、Eloquentではいろいろなカウントのコードの仕方があります。

今回は、これを説明するために、コントローラに特別にメソッドを作成してみました。

ProductController.php

namespace App\Http\Controllers\User;

use App\Http\Controllers\Controller;
use App\Product;
use App\ProductImage;

class ProductController extends Controller
{
	public function getCount(Product $product)
	{
		$count1 = ProductImage::where('product_id', $product->product_id)->get()->count();
		$count2 = ProductImage::where('product_id', $product->product_id)->count();
		$count3 = $product->product_images->count();
		$count4 = $product->product_images()->count();

		return sprintf("<pre>count1 = %d\ncount2 = %d\ncount3 = %d\ncount4 = %d\n</pre>", $count1, $count2, $count3, $count4);
	}
}

最初の、$count1は、whereでproduct_imageのレコードを絞ってgetして、それらのレコードをcount()します。しかし、getしたのはIlluminate\Database\Eloquent\Collectionのオブジェクトであり、取得したレコードのデータすべてが入っています。２，３のレコード数なら問題ないけれど、１０００とかあれば、それだけのデータがメモリーに入るわけで、単にレコード数が必要なのにとんでもない浪費です。

それに比べて次の、$count2は、SQLクエリのCOUNT(*)を使用するので、取得するのは、まさに１つのカウント数だです。$count1とは大きな違いです。

さて、Productのモデルには、

Product.php

namespace App;

use Illuminate\Database\Eloquent\Model;

class Product extends Model
{
...
    public function product_images()
    {
        return $this->hasMany('App\ProductImage');
    }
}

ProductImageとのリレーションが定義されています。

これを利用したのが、先の$count3です。コードすっきりしましたね。しかし、ここ注意してください。この取得のしかたは、先の$count1とまったく同じなのです。つまり、必要なレコードをすべて含んだCollectionを作成してから、それをカウント。

これを正しくクエリで実行してもらうのが、$count4です。ちょっとした違いですね。product_images->count()かproduct_images()->count()か。

実際、これらの実行がどうなっているかは、実行したクエリを見ればわかります。以下は、Debugbarの結果です。

カウント数は皆同じですが、２と４では、select count(*)ですが、１と３は、select *となっていますね。

Eloquentのアクセッサーの説明例

Sat, 20 Feb 2016 08:22:11 +0900

Laravelのマニュアルは、ほどよい説明で気に入っています。長い説明でポイントがつかめなく困ることはそうありません。理解には何回か読むことも必要ですが。

しかし、ときには掲載されるサンプルコードがよく使用されるような例ではなく、逆に混乱してしまうことあります。

例えば、Eloquent Mutatorsの以下のサンプルコード。

namespace App;

use Illuminate\Database\Eloquent\Model;

class User extends Model
{
    public function getFirstNameAttribute($value)
    {
        return ucfirst($value);
    }
}

getFirstNameAttributeを上のように定義すると、

$user = App\User::find(1);

$firstName = $user->first_name;

のように使えると。

ucfirstの関数は、文字列の最初の文字を大文字にする関数なので、もとのDBテーブルuserのfirst_nameの項目の値、つまり$user->first_nameが変換されるのだな、とは推測できます。

しかし、元の項目名もfirst_nameであるし、変換した値にアクセスするのもfirst_nameで、同じ変数名でややこしく思いませんか？

テンプレートで使用するなら、こちらの方が混乱せずに管理性が高いです。 {{ ucfirst($user->first_name) }}

アクセッサーの便利さの説明には、違うサンプルコードを使用した方が良いと思います。

例えば、

    public function getNameAttribute()
    {
        return $this->first_name.' '.$this->last_name;
    }

この例では、nameという項目はDBテーブルに存在しないという仮定です。

$user = App\User::find(1);

echo $user->name;

$user->first_nameが「Kenji」で、$user->last_nameが「Hino」なら、「Kenji Hino」が表示されます。つまり、モデルに新規の属性を作成するのは簡単ということが、このサンプルからわかります。

注意してもらいたいのは、関数名にパラメータがないことです。最初の例では、$valueがありました。そのパラメータは、関数名で指定される（この場合、FisrtName => first_name）変数の値をとってくるという意味ですね。

さて、この新規の属性name、他のDBから入ってくる属性と違って生成するオブジェクトに自動的にふくまれるというわけではありません。

$ php artisan tinker
Psy Shell v0.6.1 (PHP 5.6.13 — cli) by Justin Hileman
>>> use App\User;
=> false
>>> $user = User::find(1);
=> App\User {#847
     id: 1,
     created_at: "2015-04-21 11:56:46",
     updated_at: "2016-01-29 14:17:54",
     first_name: "Kenji",
     last_name: "Hino",
   }
>>> $user->name;
=> "Kenji Hino"
>>> $user->toArray()
=> [
     "id" => 1,
     "created_at" => "2015-04-21 11:56:46",
     "updated_at" => "2016-01-29 14:17:54",
     "first_name" => "Kenji",
     "last_name" => "Hino",
   ]
>>>

最初のオブジェクトの属性としては、nameは入ってきませんね。しかし、$user->nameでは値が返ってきます。しかし、toArrayやtoJsonでは入ってきません。

これは、パフォーマンスのためにLaravelの意図的な仕様です。毎回毎回必要なものでもありませんね。

しかし、必要なときにはどうしたらよいのでしょう？

class User extends Model
{
    protected $appends = ['name'];
...

と$appendsに新規属性を指定すると、

>>> $user->toArray()
=> [
     "id" => 1,
     "created_at" => "2015-04-21 11:56:46",
     "updated_at" => "2016-01-29 14:17:54",
     "first_name" => "Kenji",
     "last_name" => "Hino",
     "name" => "Kenji Hino",
   ]
>>>

name入ってきますね。

ああも言えたりこうも言えたり

Mon, 31 Aug 2015 07:55:40 +0900

Laravelでは、同じことを成し遂げるのにいくつか違う方法で行うことできます。これを便利かと思うかややこしいかと思うかは、人それぞれですが、

例えば、前回のマスアサインメントの紹介をしたときの以下のコード、

class SignupController extends Controller
{
  public function postSignup(Request $request)
  {
    $member = new Member;
    $member->fill($request->all())->save();
  }
}

これ以下のようにも書けるのですよ。

インスタンスを作成するクラス・メソッドで、コンパクトに。

class SignupController extends Controller
{
  public function postSignup(Request $request)
  {
    $member = Member::create($request->all());
  }
}

あるいは、パラメータでインスタンスを作成してまって、値を入れてセーブ。

class SignupController extends Controller
{
  public function postSignup(Request $request, Member $member)
  {
    $member->create($request->all());
  }
}

これら皆同じくDBにレコードを作成します。

マスアサインメントで一括取り込み

Wed, 19 Aug 2015 09:31:52 +0900

ララベルのマニュアルで紹介されている一般的なDBレコードの作成方法は、

class Member extends Model
{
  protected $table = 'member';
  protected $primary_key = 'member_id';
  protected $timestamps = true;
}

use App\Models\Member;

$member = new Member();
$member->name = '山田太郎';
$member->email = 'tyamada@gmail.com';
$member->password = 'password'; //　ここもちろん実際は暗号化して
$member->save();

Memberのインスタンスを作成し、ちまちまとそれぞれの項目を埋めて、最後にセーブ。

しかし、ウェブのアプリでは、コントローラーにおいて、ユーザーの入力がたくさんの項目でいっぺんに入ってくるので、

namespace App\Http\Controllers;

use App\Models\Member;
use Illuminate\Http\Request;
use App\Http\Controllers\Controller;

class SignupController extends Controller
{
  public function postSignup(Request $request)
  {
    $member = new Member;
    $member->fill($request->all())->save();
  }
}

と、先のようにひとつひとつの項目に値を割り当てずに、一気に保存することできます。いわゆる、一括割り当てのマスアサインメント(Mass Assignment)です。

しかし、このコード、ちょっと問題があります。

上のコードでは、フォームからポストされる項目名がすべてが、クラスMemberのDBテーブルにあると仮定して、ララベルは一括割り当てを試みます。

たとえば、以下のようなフォームでは、

    <form method="post" action="signup">
        ログイン:
        <input type="email" name="email" value="{{ old('email') }}" required autofocus>

        パスワード:
        <input type="password" name="password" required>

        パスワードの確認:
        <input type="password" name="password_confirmation" required>
        
        名前:
        <input type="text" name="name" value="{{ old('name') }}" required>

        <button type="submit">保存</button>

    </form>

以下の項目が入力項目名ですが、

email password password_confirmation name

password_confirmationは、通常、パスワード確認のための入力項目でDBには存在しない項目です。その値をDBに入れようとするところでエラーとなります。

どうしましょう？

エロクエント（Eloquent）では、どの値をDBに入れてよいか、どれを入れていけないかのルールの設定が可能です。$fillableあるいは$guardedのどちらかの変数の定義がその目的で使用されます。前者は、ホワイトリスト（入力OKの項目のリスト）、後者はブラックリスト（入力禁止の項目のリスト）です。

class Product extends Model
{
  protected $table = 'member';
  protected $primary_key = 'member_id';
  protected $timestamps = true;

  protected $fillable = ['email', 'password', 'name'];
}

こうすれば、エラーがなくDBに値を無事に入れることができます。

$fillableの代わりに、以下でも良いですね。

protected $guarded = ['password_confirmation'];

アーティザンのティンカー

Wed, 12 Aug 2015 12:44:26 +0900

前回の投稿「ダーティーなレコード」で、DBレコードが更新されたかどうか、簡単に実験してチェックできるツールを紹介しましょう。

ララベルにはコマンドで実行できる強力なツール、その名もアーティザン(Artisan)があります。このアーティザン、Macを含めてUnix系の開発者には便利でこのうえないツール。しかも、複数のコマンドがあるわけでなく、１つのコマンドでオプションを変えるだけでいろいろなことができる優れもの。

$ php artisan list

とタイプすればたくさんのオプションのヘルプがでてきます。

さて、この中でとてもユニークなのが、今回紹介するTinker

$ php artisan tinker

Psy Shell v0.4.4 (PHP 5.5.25 - cli) by Justin Hileman
>>>

まず、Eloquentのモデルを利用してレコードを取ってきましょう.

>>> use App\Models\Product
=> false
>>> $product = Product::find(1)
=> <App\Models\Product #000000000db510bc000000004b81eec1> {
       product_id: 1,
       created_at: "2015-04-25 12:22:10",
       updated_at: "2015-08-05 13:15:25",
       name: "test product",
       price: "1000"
   }
>>>

次に、価格（price）を更新してみます。

>>> $product->price = "2000"
=> "2000"
>>> $porduct->isDirty()
=> true
>>> $product->save()
=> true
>>> $product
=> <App\Models\Product #000000000ee7a5b70000000066692faa> {
       product_id: 1,
       created_at: "2015-04-25 12:22:10",
       updated_at: "2015-08-11 09:33:23",
       name: "test product",
       price: "2000"
   }
>>>

isDirty()は変更されたのでもちろんtrue、また update_atも更新時の日時に更新されています。

今までのDBのクエリの履歴を見たいなら、

>>> DB::getQueryLog()
=> [
       [
           "query"    => "select * from `product` where `product`.`product_id` = ? limit 1",
           "bindings" => [
               3
           ],
           "time"     => 0.56
       ],
       [
           "query"    => "update `product` set `updated_at` = ?, `price` = ? where `product_id` = ?",
           "bindings" => [
               "2015-08-11 09:33:23",
               "2000",
               3
           ],
           "time"     => 3.13
       ]
   ]
>>>

さて、今度は同じ値を入れてみましょう。

>>> $product->price = "2000"
=> "2000"
>>> $product->isDirty()
=> false
>>> $product->save()
=> true
>>> $product
=> <App\Models\Product #000000000ee7a5b70000000066692faa> {
       product_id: 1,
       created_at: "2015-04-25 12:22:10",
       updated_at: "2015-08-11 09:33:23",
       name: "test product",
       price: "2000"
   }
>>>

レコードではダーティーではなく(false)、またsave()しているにもかかわらず、update_atの値にも変化ありませんね。

ここで、DB::geQueryLog()を実行すれば、さきとまったく同じ履歴が出てきます。つまり、DBの処理は何もなかったを証明します。

ティンカー便利ですね。ブラウザを使わなくとも、ユニットテストを書かなくても、ここでテストができるのが便利です。

追記：

今回のティンカーは、バージョン5.1のララベルを使用しています。他のバージョンでは、コマンドのプロンプトのシンボルが違ったりや行末のセミコロンの必須となったります。ご注意を。

ダーティなレコード

Wed, 05 Aug 2015 12:13:26 +0900

フォームの画面でのユーザーのインプットをもとに既存のDBレコードを更新する際、もし何もデータ更新なしに「保存」ボタンを押されたらDBレコードを更新する？

更新あります！

もちろん、Javascriptで「保存」ボタンを無効にすることも可能。少なくともブラウザレベルでは。

しかしサーバーレベルではどう判断？

現在のデータとインプットデータを項目ごとに１つずつ比較？

そんな面倒なことを裏で自動的にEloquentは行ってくれます。

例えば、

class Product extends Model {
  protected $table = 'product';
  protected $primary_key = 'product_id';
  protected $timestamps = true;
}

use App\Product;

$product = Product::find(1); //product_id = 1　のレコードをゲット
$product->price = 2000;　// まったく以前と同じ値段に
$product->update();

update()をコールしているのだけれど、何もデータに変更ないので、ここ裏ではDBの更新はありません（updated_atのタイムスタンプをチェックしてみてください）。賢いですね！

しかし、ここに例えば、この更新をもとに他のDBのレコードを更新することがプログラムされていたら？

$product->update();
update_other_table();

必要もないのにそちらも更新されては困ります。

更新されたかどうかを判断するには、

if($product->isDirty())
{
  $product->update();
  update_other_table();
}

と簡単にチェックできます。ここisDirty()はDBにレコードが保存される前にチェックする必要あります。つまり、update()の前に。

さらに、１つの項目だけが変更されたかどうかをチェックするには、

if($product->isDirty('price'))
{
  update_other_table();
}

素晴らしいですね。

ちなみに、この「ダーティ」。ダーティハリー、ダーティダンシングのムービーの「ダーティ」と同じです。

http://dictionary.goo.ne.jp/leaf/jn2/132268/m0u/

汚いの意味。

でもここでの意味は、「データが更新された」の意味。