Factory on ララジャパン

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()というメソッドもないのです。滅多に直面するケースは少ないですが、注意しましょう。

Laravel 8.x更新で変わったこと（３）factoryがクラス化される

Fri, 05 Nov 2021 11:22:00 +0900

さらに引き続いて、最新のバージョンのLaravel 8.xの話です。今回はfactoryの話です。

結構変わりました。これもL7.xと比較してみましょう。

L7.xでは、namespaceがありません。

app/database/factories/UserFactory.php

/** @var \Illuminate\Database\Eloquent\Factory $factory */

use App\User;
use Faker\Generator as Faker;
use Illuminate\Support\Str;

/*
|--------------------------------------------------------------------------
| Model Factories
|--------------------------------------------------------------------------
|
| This directory should contain each of the model factory definitions for
| your application. Factories provide a convenient way to generate new
| model instances for testing / seeding your application's database.
|
*/

$factory->define(User::class, function (Faker $faker) {
    return [
        'name' => $faker->name,
        'email' => $faker->unique()->safeEmail,
        'email_verified_at' => now(),
        'password' => '$2y$10$92IXUNpkjO0rOQ5byMi.Ye4oKoEa3Ro9llC/.og/at2.uheWG/igi', // password
        'remember_token' => Str::random(10),
    ];
});

L8.xでは、以下のようにnamespaceが入り、Factoryを継承したクラスとなりました。

app/database/factories/UserFactory.php

namespace Database\Factories;

use App\Models\User;
use Illuminate\Database\Eloquent\Factories\Factory;
use Illuminate\Support\Str;

class UserFactory extends Factory
{
    /**
     * The name of the factory's corresponding model.
     *
     * @var string
     */
    protected $model = User::class;

    /**
     * Define the model's default state.
     *
     * @return array
     */
    public function definition()
    {
        return [
            'name' => $this->faker->name(),
            'email' => $this->faker->unique()->safeEmail(),
            'email_verified_at' => now(),
            'password' => '$2y$10$92IXUNpkjO0rOQ5byMi.Ye4oKoEa3Ro9llC/.og/at2.uheWG/igi', // password
            'remember_token' => Str::random(10),
        ];
    }

    /**
     * Indicate that the model's email address should be unverified.
     *
     * @return \Illuminate\Database\Eloquent\Factories\Factory
     */
    public function unverified()
    {
        return $this->state(function (array $attributes) {
            return [
                'email_verified_at' => null,
            ];
        });
    }
}

使用の方は、

L7.xでは、以下のようにクラスのないphp関数だったのが、

factory(App\User::class, 50)->create(); // Userのレコードを50作成

L8.xでは、

User::factory()->count(50)->create();

クラスメソッドとなります。

User::factory()として使えるのは、以下のようにUserモデルにおいてHasFactoryのトレイトを使用しているからです。

app/Models/User.php

namespace App\Models;

use Illuminate\Contracts\Auth\MustVerifyEmail;
use Illuminate\Database\Eloquent\Factories\HasFactory;
use Illuminate\Foundation\Auth\User as Authenticatable;
use Illuminate\Notifications\Notifiable;
use Laravel\Sanctum\HasApiTokens;

class User extends Authenticatable
{
    use HasApiTokens, HasFactory, Notifiable;
..

最後に、これもLaravel ShiftのアップグレードサービスですべてのFactoryの定義の変換とモデルのクラスの定義にuse HasFactory;を追加してくれるところまで自動変換してくれます。

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へのクエリ発行がプログラムにおいて如何に重い処理か、という事を示しています。普段コードを書く際にも無駄なクエリを発行していないか気をつけねば、と思った次第です。

データベースのテスト

Sat, 01 Feb 2020 02:18:37 +0900

既存のDBのそれぞれのテーブルにおいて、migrationファイルやfactoryファイルが揃ったところで、phpunitのテストを作成して実行してみましょう。

テストDBの作成

テストDBは、phpunitのためだけのDBとなるゆえに、ブラウザでアクセスする本DBとは違うDBを作成します。つまり、開発サイトでは、プロジェクト１つに対して２つのDBを持つことになります。

本DBは、mysqlで、テストのDBには、sqliteという設定がドキュメントでも一般のLaravelの記事でも書かれていますが、私はテストといえども、本DBもテストDBも同じmysqlを使用することを勧めます。条件をまったく同じとしたいからです。

まず、mysqlのコマンドで、テストDB（demo_test）を作成します。

$ echo "create database demo_test" | mysql -u root -p
Query OK, 1 row affected (0.00 sec)

次に、config/database.phpをエディターで開いて、mysqlのコネクションをコピーして、mysql_testのコネクションを作成します。

config/databse.php

use Illuminate\Support\Str;

return [
....
    'connections' => [
...
        'mysql' => [
            'driver' => 'mysql',
            'url' => env('DATABASE_URL'),
            'host' => env('DB_HOST', '127.0.0.1'),
            'port' => env('DB_PORT', '3306'),
            'database' => env('DB_DATABASE', 'forge'),
            'username' => env('DB_USERNAME', 'forge'),
            'password' => env('DB_PASSWORD', ''),
            'unix_socket' => env('DB_SOCKET', ''),
            'charset' => 'utf8mb4',
            '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_test' => [
            'driver' => 'mysql',
            'url' => env('DATABASE_URL'),
            'host' => env('DB_HOST', '127.0.0.1'),
            'port' => env('DB_PORT', '3306'),
            'database' => 'demo_test',
            'username' => 'root',
            'password' => 'secret',
            'unix_socket' => env('DB_SOCKET', ''),
            'charset' => 'utf8mb4',
            '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_testにおいて編集した項目は、database、username、passwordです。env()を使用せずに、固定としています。必要なら他の項目も同様に編集してください。それから、usernameに指定するmysqlのユーザーは必ず、drop table, create table, truncateのsql文と実行できる権限を持つユーザーである必要があります。それゆえに、ここではrootのmysqlユーザーを使用しています。

次に、テーブル作成のartisanコマンドを実行して、テストDBにテーブルを作成します。前回で作成したmigrationファイルがここで役立ちます。

$ php artisan migrate:fresh --database=mysql_test
Dropped all tables successfully.
Migration table created successfully.
Migrating: 2014_10_12_000000_create_users_table
Migrated:  2014_10_12_000000_create_users_table (0.03 seconds)
Migrating: 2014_10_12_100000_create_password_resets_table
Migrated:  2014_10_12_100000_create_password_resets_table (0.02 seconds)
Migrating: 2019_08_19_000000_create_failed_jobs_table
Migrated:  2019_08_19_000000_create_failed_jobs_table (0.01 seconds)

必ず、–databaseでmysql_testのコネクションを指定ください。指定しないと、本DBの方が空となってしまうので注意を！

phpunitの設定

テストDBをテストの実行で使用するには、phpunit.xmlの編集が必要です。

phpunit.xml

<?xml version="1.0" encoding="UTF-8"?>
<phpunit xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:noNamespaceSchemaLocation="./vendor/phpunit/phpunit/phpunit.xsd"
         backupGlobals="false"
         backupStaticAttributes="false"
         bootstrap="vendor/autoload.php"
         colors="true"
         convertErrorsToExceptions="true"
         convertNoticesToExceptions="true"
         convertWarningsToExceptions="true"
         processIsolation="false"
         stopOnFailure="false">
    <testsuites>
        <testsuite name="Unit">
            <directory suffix="Test.php">./tests/Unit</directory>
        </testsuite>

        <testsuite name="Feature">
            <directory suffix="Test.php">./tests/Feature</directory>
        </testsuite>
    </testsuites>
    <filter>
        <whitelist processUncoveredFilesFromWhitelist="true">
            <directory suffix=".php">./app</directory>
        </whitelist>
    </filter>
    <php>
        <server name="APP_ENV" value="testing"/>
        <server name="BCRYPT_ROUNDS" value="4"/>
        <server name="CACHE_DRIVER" value="array"/>
        <server name="DB_CONNECTION" value="mysql_test"/>
        <server name="MAIL_DRIVER" value="array"/>
        <server name="QUEUE_CONNECTION" value="sync"/>
        <server name="SESSION_DRIVER" value="array"/>
    </php>
</phpunit>

DB_CONNECTIONをmysql_testと指定しています。

さて、これでphpunitを実行できます。vendor/bin/phpunitは、このプロジェクトでインストールされたバージョンのphpunitなので、必ずそのパスを使用してください。

$ vendor/bin/phpunit
PHPUnit 8.5.2 by Sebastian Bergmann and contributors.

..                                                                  2 / 2 (100%)

Time: 335 ms, Memory: 16.00 MB

OK (2 tests, 2 assertions)

OKがテスト成功、という意味です。

RefreshDatabaseトレイト

先のphpunitの実行では、データベースのテストは含まれていません。作成してみましょう。

$php artisan make:test --unit UserTest
Test created successfully.

この実行で、tests/Unit/UserTest.phpのファイルが作成されますが、それを以下のように編集します。

UserTest.php

namespace Tests\Unit;

// use PHPUnit\Framework\TestCase // Laravel 6.xで生成されるが、コメントして以下を追加
use Tests\TestCase;

use Illuminate\Foundation\Testing\RefreshDatabase; // 追加

use App\User;

class UserTest extends TestCase
{
    use RefreshDatabase;

    public function test_create_a_user()
    {
        factory(User::class)->create(); // usersのDBテーブルにレコードを１つ作成

        $this->assertCount(1, User::all()); // すべてのレコードを取得してレコード数が１であることを確認
    }
}

実行してみましょう。

$ vendor/bin/phpunit --filter UserTest
PHPUnit 8.5.2 by Sebastian Bergmann and contributors.

.                                                                   1 / 1 (100%)

Time: 511 ms, Memory: 22.00 MB

OK (1 test, 1 assertion)

成功ですね。

このテストは何回実行しても成功となります。

$ vendor/bin/phpunit --filter UserTest
PHPUnit 8.5.2 by Sebastian Bergmann and contributors.

.                                                                   1 / 1 (100%)

Time: 511 ms, Memory: 22.00 MB

OK (1 test, 1 assertion)
$ vendor/bin/phpunit --filter UserTest
PHPUnit 8.5.2 by Sebastian Bergmann and contributors.

.                                                                   1 / 1 (100%)

Time: 511 ms, Memory: 22.00 MB

OK (1 test, 1 assertion)

試しに、use RefershDatabaseをコメントして実行してみてください。

$ vendor/bin/phpunit --filter UserTest
PHPUnit 8.5.2 by Sebastian Bergmann and contributors.

.                                                                   1 / 1 (100%)

Time: 511 ms, Memory: 22.00 MB

OK (1 test, 1 assertion)

$ vendor/bin/phpunit --filter UserTest
PHPUnit 8.5.2 by Sebastian Bergmann and contributors.

F                                                                   1 / 1 (100%)

Time: 324 ms, Memory: 18.00 MB

There was 1 failure:

1) Tests\Unit\UserTest::testExample
Failed asserting that actual size 2 matches expected size 1.

/vol1/usr/www/repos/repos/l6x/tests/Unit/UserTest.php:23

FAILURES!
Tests: 1, Assertions: 1, Failures: 1.

１回名は成功ですが、２回目は失敗です．なぜなら、RefereshDatabaseなしではレコードは追加されていくばかりだからです。RefereshDatabaseのトレイトを使用することによりDBテーブルが空となり、毎回同じ条件でテストを実行できます。

既存のDBからfactoryファイルを自動作成

Sat, 25 Jan 2020 07:51:08 +0900

既存のＤＢからmigrationファイルを自動作成によって、テストのために空のDBテーブルの作成が可能となりました。今度は、そこへテストデータを作成するためにfactoryが必要となります。これも自動作成しましょう。

どうして、factoryのファイルが必要？

factoryのファイルが必要なのは、あらゆるテストの目的のためです。いちいち画面の入力でDBレコードを作成する代わりに、tinkerやユニットテストでfactory()のヘルパーを使用して簡単にレコードが作成できようになります。factoryのタグの記事では、たくさんの使用例を見ることできます。

しかし、現状の以下のLaravelのコマンドの実行では、

$ php artisan make:factory UserFactory --model=User

作成されるfactoryは、以下のように項目もない単なるテンプレートです。

databases/factorys/UserFactory.php

/** @var \Illuminate\Database\Eloquent\Factory $factory */

use App\Model;
use Faker\Generator as Faker;

$factory->define(User::class, function (Faker $faker) {
    return [
        //
    ];
});

DBテーブルがたくさんあるプロジェクトでは、いちいちこれを編集していくのはとても大変です。それゆえに、既存のDB構造をもとに、自動でfactoryファイルを生成する必要があります。

factoryファイル自動生成ツール

まずは、パッケージのインストール。以下をコマンドラインで実行します。

$ composer require --dev mpociot/laravel-test-factory-helper

factoryのファイルを作成するには、artisanの実行が必要となります。Laravel 6.x の新規プロジェクトを作成して実行しますが、すでにUserのモデルのためのfactoryファイルが、databases/factories/UserFactory.phpとして存在するので、上書きされないように改名しておきます。そして以下をコマンドラインで実行します。

$ php artisan generate:model-factory
Model factory created: database/factories/UserFactory.php

作成されたfactoryの内容は以下です。

databases/factories/UserFactory.php

/* @var $factory \Illuminate\Database\Eloquent\Factory */

use Faker\Generator as Faker;

$factory->define(App\User::class, function (Faker $faker) {
    return [
        'name' => $faker->name,
        'email' => $faker->safeEmail,
        'email_verified_at' => $faker->dateTime(),
        'password' => bcrypt($faker->password),
        'remember_token' => Str::random(10),
    ];
});

元にあったファイルと比べてみましょう。以下が元のファイルです。

/** @var \Illuminate\Database\Eloquent\Factory $factory */

use App\User;
use Faker\Generator as Faker;
use Illuminate\Support\Str;

$factory->define(User::class, function (Faker $faker) {
    return [
        'name' => $faker->name,
        'email' => $faker->unique()->safeEmail,
        'email_verified_at' => now(),
        'password' => '$2y$10$92IXUNpkjO0rOQ5byMi.Ye4oKoEa3Ro9llC/.og/at2.uheWG/igi', // password
        'remember_token' => Str::random(10),
    ];
});

いくつか違いがありますね。しかし、これも自動生成されたmigrationファイルと同様に使用するテストに合わせて編集すればよいです。 Fakerのドキュメントは、こちらです。

factoryファイル自動作成のコマンドのartisanの実行には、いくつかのオプションを指定することができます。

すべてのモデルのfactoryを作成する代わりに、指定のモデルだけのfactoryの作成には、

$ php artisan generate:model-factory User Team

モデルのファイルがが、app/Modelsのディレクトリにあるなら、

$ php artisan generate:model-factory --dir app/Models -- User Team

と実行できます。

最後に、migrationとfactoryの自動作成ツールは、Laravelのバージョンによりインストールが違うのでここでまとめてリストします。

Laravel 6.x

$ composer require --dev oscarafdev/migrations-generator 2.0.13
$ composer require --dev mpociot/laravel-test-factory-helper

Laravel 5.5~

$ composer require --dev xethron/migrations-generator
$ composer require --dev mpociot/laravel-test-factory-helper v1.3

ブラウザからtinkerにアクセス

Fri, 13 Sep 2019 23:14:31 +0900

tinker好きの私としては、嬉しいニュースです。今までコンソールからでしか使用できなかったtinkerがブラウザでアクセスできるようになりました。と言っても、Laravelのパッケージの一部ではなく、Laravelのtinkerにフロントエンドを追加したphpのパッケージ、Web Tinkerのことです。

インストール

まず、パッケージのレポは以下のGitHubです。

https://github.com/spatie/laravel-web-tinker

これによると、まずcomposerの実行です。–devのオプションが必要なことに注意してください。ウェブからのアクセスが可能なので、これなしではproduction版でアクセスされて、セキュリティの問題となります。

$ composer require spatie/laravel-web-tinker --dev

次に、以下の実行でWeb Tinkerのアセットをpublic/vendor/web-tinkerのディレクトリにインストールします。

$ php artisan web-tinker:install

フロントエンド

早速、ブラウザからアクセスしてみましょう。url + ‘/tinker’でアクセスできます。

実行には、cmd+enter あるいは ctrl+enterとあります。コンソール版のtinkerとは違って、１行タイプしてenterで実行とはいかないようです。

とりあえず、以下のように実行してみました。

結果が右パネルに出ましたね。

しかし、以下のように２行タイプすると、右パネルがクリアされて最後の行の結果のみが出力されます。

コンソール版のtinkerと違い、実行の ctrl+enterを押すと、画面に入力したコードすべて（複数行あっても）が実行されるようです。たとえ最初の１行目にカーソルを持っていき実行しても同じ結果です。これは、複雑なコードのテストには理想かもしれません。例えば、以前に掲載した複雑なコードは、コンソール版にtinkerでは以下のように１行１行タイプ実行していきます。８行目のファクトリーの実行では長い１行となっているので、括弧の数など間違わないように注意が必要です。

$ 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
...

しかし、Web Tinkerでは、以下のように直接プログラムからのチャンクのコードをコピペしてそのまま実行できます。

これは便利です。

それから、コンソール版と比べて、毎回の実行において環境がリロードされるので、コンソール版のように、プログラム変更するたびに、exitして再度php artisan tinkerする必要がないのもプラスです。

マイナーなマイナスの面では、編集にemacsのキー、つまり、control + a（行先頭へ移動）、control + e （行末へ移動）などが使えないことです。私（だけ？）にとっては少し残念なことです。コンソール版ではそれらのキーは重宝しています。

結論としては、コンソール版のtinkerを捨てて、このウェブ版のtinkerに乗り換えることはできませんが、目的によって使い分けをすれば十分パワフルなツールとして使えそうです。

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()はいったいどういうときに使用するのでしょうかね。

Googleデータポータル：データソースとレポートの作成

Mon, 22 Jul 2019 03:14:11 +0900

以前からお客さんのプロジェクトの管理画面のダッシュボードに日別や月別の売り上げ合計や会員の獲得数などをグラフで表示したいと思っていました。もちろん、グラフを作成するjavascriptのライブラリはいくつかありますが、習得にも開発にも時間がたくさんかかりそうです。そこで私の目に留まったのが、Googleデータポータル。データソースを指定してビジュアルなツールでちょいちょいとグラフ化できそうです。今回は、それを使用してMySQLのデータベースから月別に登録した会員数の棒グラフの作成の仕方を説明します。

完成は以下のような画面です。

準備：データベース

まず、データポータルが取得してくるデータのソースとなるデータベースの準備が必要です。コマンドラインから、以下を実行します。

$ mysql -u root mysql -p
Enter password: 
mysql> create database l58;
mysql> create user 'gds'@'%' identified by 'password';
mysql> grant select on l58.* to 'gds'@'%';

データベース名　⇒　l58 ユーザー名　⇒　gds パスワード　⇒　password 権限　⇒　SQL文でSELECTのみの実行が可能 アクセス権限　⇒　インターネットのどこからも（上では、‘gds’@’%‘の%の指定により）

という設定です。しかし、たとえパスワードの認証があってもインターネットのどこからでもこのDBにアクセスできるのは不安ですね。これに関しては後に対応します。

次は、このデータベースを使用するLaravelのプロジェクトの作成ですが、ここでは最新のLaravelのバージョン（5.8）をインストールしたと仮定します。.envの設定には先のデータベース情報を使用することを忘れずに。

このデータベースでのDBテーブルの作成は、以下のようにmigrateを実行します。

$ php artisan migrate
Dropped all tables successfully.
Migration table created successfully.
Migrating: 2014_10_12_000000_create_users_table
Migrated:  2014_10_12_000000_create_users_table (0.02 seconds)
Migrating: 2014_10_12_100000_create_password_resets_table
Migrated:  2014_10_12_100000_create_password_resets_table (0.02 seconds)

今度は、DBテーブル、usersを会員のテーブルとして、ここにフェイクの会員レコードを100個作成します。もちろん、factory()のヘルパーを使用してレコード作成となりますが、１つ問題があります。デフォルトの設定では、作成された会員のレコード作成日時(created_at)が皆作成日が同じになってしまうのです。これでは月別の棒グラフでは今月のみの表示となってしまいます。

Fakerのドキュメントを閲覧すると、dateTimeThisYear()という関数があり、多分に今年の日付をランダムに作成してくれるようです。この関数を使い、以下のようにUserFactory.phpを編集して、created_atに値がランダムに振り当てられるようにします。

...                                                                                                                                                                                                 
$factory->define(User::class, function (Faker $faker) {                                                                                                                                                            
    $dtm = $faker->dateTimeThisYear($max = 'now', $timezone = 'Asia/Tokyo');                                                                                                                                       
                                                                                                                                                                                                                   
    return [                                                                                                                                                                                                       
        'name' => $faker->name,                                                                                                                                                                                    
        'email' => $faker->unique()->safeEmail,                                                                                                                                                                    
        'email_verified_at' => now(),                                                                                                                                                                              
        'password' => '$2y$10$92IXUNpkjO0rOQ5byMi.Ye4oKoEa3Ro9llC/.og/at2.uheWG/igi', // password                                                                                                                  
        'remember_token' => Str::random(10),                                                                                                                                                                       
        'created_at' => $dtm,                                                                                                                                                                                      
        'updated_at' => $dtm,                                                                                                                                                                                      
    ];                                                                                                                                                                                                             
});

用意ができたところで、いつものようにtinkerでレコード作成してみましょう。

>>>  factory(App\User::class, 100)->create();
=> Illuminate\Database\Eloquent\Collection {#2982
     all: [
       App\User {#2978
         name: "鈴木 直子",
         email: "kana93@example.com",
         email_verified_at: "2019-07-18 20:06:46",
         created_at: "2018-10-13 10:06:32",
         updated_at: "2018-10-13 10:06:32",
         id: 1,
       },
       App\User {#2976
         name: "伊藤 幹",
         email: "shuhei93@example.com",
         email_verified_at: "2019-07-18 20:06:46",
         created_at: "2019-05-17 21:42:06",
         updated_at: "2019-05-17 21:42:06",
         id: 2,
       },
     ...

100個レコードできました。意図通りに、作成日時（created_at）もレコードごとに違います。しかし、何故か去年のレコードが作成されているのは変ですね。いつか調べてみます。

準備：MySQLのセキュリティ

先ほど設定したデータベースは、ユーザー情報があればインターネットのどこからでも3306のポートでアクセスできます。Googleデータポータルだけからのアクセスに制限したいなら、ここで書かれているIPのみに制限を課すことができます。

AWSならEC2でセキュリティグループを作成して以下のIPだけから、MySQLのポート(3306)にアクセスできる制限を設定できます。そして、このセキュリティグループを使用しているEC2のセキュリティに追加すればよいです。

データソースの作成

データベースとデータの準備ができたところで、今度はGoogleデータポータルに移ります。まずは、先のデータベースに接続するために、データソースなるものを作成します。Googleのアカウントですでにログインしていると仮定して、こちらへアクセスしてください。

以下の画面で、作成ボタンを押して、データソースを選択します。

次に、数あるデータコネクタから、MySQLを選択します。左上のデータソース名を無題から改名することもお忘れずに。

今度は、データベース情報を入力して、認証ボタンを押します。

認証が成功すると、DBテーブルのリストが右に表示されます。そこから、使用したいDBテーブルを選択します。ここでは、会員のusersを選択します。そして、右上の再接続をクリックしてください。

再接続したのちに表示される画面は、DBテーブル、usersの項目のリストです。なぜか、create_at, updated_atのtimestampの項目は「テキスト」となっているので、以下のように日時のタイプを選択しておいてください。

もう１つの作業として、最終の棒グラフでは、X軸を年月としたいので、年月のフィールドをcreated_atをもとに作成します。

以下のように、フィールドを追加で開かれる画面で、計算式をTODATE(created_at,‘DEFAULT_DECIMAL’, ‘%Y-%m’)と設定します。ここ、MONTH(created_at)のように思われますが、グラフが月別の表示とならなくうまく行きません。Googleデータポータルは、MySQLのtimestampのデータタイプを文字列とみなしているためかもしれません。

レポートの作成

フィールドの設定が完了したところで、このデーターソースを使ってレポートを作成します。画面右上のレポートを作成ボタンを押してください。

開かれた画面で、縦棒グラフを追加します。

次に、以下のように、棒グラフの右のパネルで指定します。「使用可能な項目」から、適切な項目をドラグして以下にドロップします。

上の画面で行った設定は、 データソース ⇒ DS MySql（すでにデフォルトで設定されている） 期間のディメンション ⇒　created_at ディメンション ⇒ 年月指標　⇒　idをドラグして、名前を「会員数」とし、集計方法を「件数」に変更。 並べ替え ⇒　年月。降順から昇順に変更。

こう設定すると、X軸に年月、Y軸にに会員数と、指定のデータベースのデータをもとにした棒グラフが期待通りに表示されます。

表示モードとするとこのポストの最初の画面となります。右上の期間の指定を変えてみてください。応じて、棒グラフが変わります。

最後に、ここで作成したレポートは、どのように管理画面にはめ込むのでしょうか？それは次回のポストとします。

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が更新されたときのみ、以下のコードを実行
        ...
    }
}
...

Laravel 5.7に更新

Fri, 07 Jun 2019 02:36:01 +0900

Laravelは一昨年あたりから細目に更新を出すようになりました。と言っても、年に2回ですが、Laravelで書いた大きなプログラムを管理する私としてはそれでも「きつい」。それで長期サポートの5.5にあぐらをかいているわけだが、しかし。

以下は5.7に掲載されていたサポートのスケジュール表。

これによると、5.5のバグ修正は今年の8月で終了ではないですか、ということで、急いで更新のキャッチアップとなりました。更新に関して私が気づいた点をいくつか書きます。5.6の更新はどうしたんだい？と思う方、すいません、変更はマイナーなので記事とするほど書くことは少なく。しかし、実際には5.5 ⇒ 5.6、5.6 ⇒ 5.7と順番に進める必要はあります。

フェイカーの言語設定

「hasManyのフェイクデータの作成」の記事で、フェイカーを使用して日本語のフェイクデータの作成に、ちらと触れましたが、この設定は、今までのデフォルトのconfig/app.phpのファイルには含まれていませんでした。このバージョンから、以下のように含まれています。

config/app.php

...
    /*
    |--------------------------------------------------------------------------
    | Faker Locale
    |--------------------------------------------------------------------------
    |
    | This locale will be used by the Faker PHP library when generating fake
    | data for your database seeds. For example, this will be used to get
    | localized telephone numbers, street address information and more.
    |
    */

    'faker_locale' => 'en_US',
...

もちろん、

'faker_locale' => 'ja_JP',

と変えましょう。

早速tinkerでテストしてみましょう。

Psy Shell v0.9.9 (PHP 7.2.16 — cli) by Justin Hileman
>>> factory(App\User::class)->make()
=> App\User {#3191
     name: "井高 拓真",
     email: "wkimura@example.net",
     email_verified_at: "2019-06-05 19:46:16",
   }

Bladeのorが??に変わる

layout.blade.phpのように使用するプログラムが同じBladeを共有するときに、例えば、プログラムにより$titleという変数が未定義になるかもしれないとすると、Bladeではこう設定してエラーとなるのを避けていました。

...
{{ $title or '' }}
...

しかし、or は、phpの??を使えば良いということで廃止になりました。??は、php7で登場した新しい比較演算子で、いちいちisset()を使用する必要がなくなりました。

...
{{ $tile ?? '' }}
...

私のプロジェクトでもいくつかこの変更の対象となるBladeのファイルがありました。ほとんどが、上記のように未定義は空として表現するので、以下のようにsedコマンドを使用して一括変換としました。

grep -rl " or ''" | grep php | xargs sed -i "s/\sor\s''/ ?? ''/g"

resources/assetsのディレクトリが廃止となる

Laravelのディレクトリ構造は、以前はバージョンが変わるごとに変わっていました。最近は落ち着いてきていいなと思っているとこれです。しかし、今回の変更は、そうたいしたことではないです。

Laravel 5.6以前は、resourcesのディレクトリの階層は、

resources
├── assets
│   ├── js
│   │   ├── app.js
│   │   ├── bootstrap.js
│   │   └── components
│   │       └── ExampleComponent.vue
│   └── sass
│       ├── app.scss
│       └── _variables.scss
├── lang
│   └── en
│       ├── auth.php
│       ├── pagination.php
│       ├── passwords.php
│       └── validation.php
└── views
    └── welcome.blade.php

が、5.7になると、

resources
├── js
│   ├── app.js
│   ├── bootstrap.js
│   └── components
│       └── ExampleComponent.vue
├── lang
│   └── en
│       ├── auth.php
│       ├── pagination.php
│       ├── passwords.php
│       └── validation.php
├── sass
│   ├── app.scss
│   └── _variables.scss
└── views
    └── welcome.blade.php

と、assetsのディレクトリの中身がすべてその上のディレクトリに移されました。また、それを反映して、webpack.mix.jsも変わっています。

しかし、この変更はオプションであり、変えたくないなら以前のままでもＯＫです。

メールログを分ける

Laravel 5.5までは、すべてのログはstorage/logs/laravel.logに保存というワンパターンであったのが、5.6ではconfig/logging.phpにおいて、いろいろなカスタマイズの設定が可能となりました。ログを従来のファイルに保存ではなくslackにも転送が可能であるし、ファイルでも従来のように１つのファイルにすべてを保存でなく、ファイル名に日付を入れて違うファイルに保存も可能です。

さらに、5.7では、config/mail.phpにおいて、

config/mail.php

...
   /*
    |--------------------------------------------------------------------------
    | Log Channel
    |--------------------------------------------------------------------------
    |
    | If you are using the "log" driver, you may specify the logging channel
    | if you prefer to keep mail messages separate from other log entries
    | for simpler reading. Otherwise, the default channel will be used.
    |
    */

    'log_channel' => env('MAIL_LOG_CHANNEL'),

のように、メールのログチャンネルも指定可能です。

例えば、

.envにおいて、

...
MAIL_DRIVER=log
...

と設定するとプログラムから送信されるメールの内容はすべて、storage/logs/laravel.logに保存されます。開発時において便利な機能です。しかし、他のエラーログとごっちゃになってわかりづらかったです。

しかし、5.7において、

config/logging.php

...
        'mail' => [
            'driver' => 'single',
            'path' => storage_path('logs/mail.log'),
            'level' => 'debug',
        ],
...

と新しくmailというログチャンネルを作成し、

.envにおいて、

...
MAIL_DRIVER=log
MAIL_LOG_CHANNEL=mail
...

と指定すれば、laravel.logではなくstorage/logs/mail.logのファイルにメールがすべて保存されるようになります。

こういうときに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文となっています。

DBにインデックスを追加

Sun, 20 Jan 2019 03:17:58 +0900

正直言って、Laravelのmigration機能は私のLaravelのプロジェクトでは使用したことありません。よく理解していないこともあり、失敗してクライアントのデータベースを空にしてしまうことを考えると悪夢です。とか言ってコマンドラインでSQL文を実行する現状もリスクはそう変わりません。ということで、前回においてmigrationを使用する機会があったので、この際にmigrationの理解を深めたいです。

DBにインデックスを追加

まず、前回においては以下のようなmigrationを作成することで新規のテーブルaddressesを作成しました。

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');
    }
}

そして、以下を実行することで、addressesのテーブルを作成できます。

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

しかし、これではusersのテーブルとのjoinにおいてパフォーマンスが良くありません。例えば、以下のようなクエリを実行するときです。

Psy Shell v0.9.3 (PHP 7.1.14 — cli) by Justin Hileman
>>> User::join('addresses', 'users.id', '=', 'addresses.user_id')->get();

SQL文では以下となります。

mysql> select * from `users` inner join `addresses` on `users`.`id` = `addresses`.`user_id`

しかし、このjoinでは、データベースはマッチするuser_idを探すために毎回addressesのレコードをすべてチェックしなければなりません。レコード数が多くなれば、クエリの実行時間はとても長くなります。

しかし、これは、addresses.user_idにインデックスを追加するだけで簡単に解決できます。

migrationを作成してインデックスを追加してみましょう。

まず、migrationを作成します。

$ php artisan make:migration change_addresses --table=addresses

作成されたファイルを編集します。

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

class ChangeAddressesTable extends Migration
{
    /**
     * Run the migrations.
     *
     * @return void
     */
    public function up()
    {
        Schema::table('addresses', function (Blueprint $table) {
            $table->index('user_id');
        });
    }

    /**
     * Reverse the migrations.
     *
     * @return void
     */
    public function down()
    {
        Schema::table('addresses', function (Blueprint $table) {
            $table->dropIndex('addresses_user_id_index');
        });
    }
}

これだけです。rollbackのためにdown()も定義することを忘れないように。dropIndex()の引数は、DBの項目名ではなく、間に下線文字を入れて、テーブル名と項目名とindexの文字列をコンバインします（例：addresses_user_id_index）。

次は、このmigrationの反映ですが、その前に–pretendのオプションでどんなSQL文が実行されるかチェックしてみます。

$ php artisan migrate --pretend
ChangeAddressesTable: alter table `addresses` add index `addresses_user_id_index`(`user_id`)

いいですね。思い通りです。

実際にmigrateします。

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

住所タイプの導入とユニークインデックスの追加

次は、もう少し複雑なケースを見てみましょう。

現在は、1ユーザー(usersの1レコード）において、複数の住所（addressesのレコード）を紐づけることができますが、住所が会社のものか自宅なのか別荘（夢）なのかわかりません。そこで、その情報を保存するために住所タイプなるtypeという項目を追加します。

migrationを作成します。

$ php artisan make:migration change_addresses2 --table=addresses

作成されたファイルを編集します。

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

class ChangeAddresses2Table extends Migration
{
    /**
     * Run the migrations.
     *
     * @return void
     */
    public function up()
    {
        Schema::table('addresses', function (Blueprint $table) {
            // 項目の追加
            $table->string('type')->after('user_id');

            // インデックスを付け直す
            $table->dropIndex('addresses_user_id_index');
            $table->unique(['user_id','type']);
        });
    }

    /**
     * Reverse the migrations.
     *
     * @return void
     */
    public function down()
    {
        Schema::table('addresses', function (Blueprint $table) {
            $table->string('type')->after('user_id');                                                                                                                                                              
                                                                                                                                                                                                                   
            $table->dropIndex('addresses_user_id_index');                                                                                                                                                          
            $table->unique(['user_id','type']);  
        });
    }
}

typeの項目の追加の後には、現在のインデックスを削除して新規にuser_idとtypeをコンバインしたインデックスを追加しなおします。そして、1ユーザーに対して住所タイプは同じものを使用できない制限のために、unique()の関数を使用します。

またもや、–pretendでSQL文をチェックします。

$ php artisan migrate --pretend
ChangeAddresses2Table: alter table `addresses` add `type` varchar(191) not null after `user_id`
ChangeAddresses2Table: alter table `addresses` drop index `addresses_user_id_index`
ChangeAddresses2Table: alter table `addresses` add unique `addresses_user_id_type_unique`(`user_id`, `type`)

次は、migrateの実行なのですが、すでにデータがある状態で実行するとレコード重複のエラーが出る可能性あります。とくにすでに１ユーザーに対して複数の住所のレコードがある場合は、それらの項目に新規の項目typeに空が入ってくるからです。

今回は、このエラーを避けるために、migrate:freshを実行します。すべてのテーブルをdropしてから作成したmigrationをすべて実行してくれます。

$ php artisan migrate:fresh
Dropped all tables successfully.
Migration table created successfully.
Migrating: 2014_10_12_000000_create_users_table
Migrated:  2014_10_12_000000_create_users_table
Migrating: 2014_10_12_100000_create_password_resets_table
Migrated:  2014_10_12_100000_create_password_resets_table
Migrating: 2019_01_10_140631_create_addresses_table
Migrated:  2019_01_10_140631_create_addresses_table
Migrating: 2019_01_15_132109_change_addresses_table
Migrated:  2019_01_15_132109_change_addresses_table
Migrating: 2019_01_18_131940_change_addresses2_table
Migrated:  2019_01_18_131940_change_addresses2_table

しかし、実際のプロダクションではできないことですね。データ皆空になってしまうし。その対応は課題としましょう。

フェイクデータの作成

さて、DBテーブルができたところで、前回のようにフェイクデータの作成をしてみたいです。

今回追加したtypeの項目のために、database/factories/AddressFactory.phpを編集します。

use Faker\Generator as Faker;

$factory->define(App\Address::class, function (Faker $faker) {
    return [
       'type'    => $faker->randomElement(['自宅', '会社']),
       'address' => $faker->address
    ];
});

tinkerで実行してみます。

>>> factory(App\User::class,3)->create()->each(function ($user) { $user->addresses()->save(factory(App\Address::class)->make()); });
...
User::join('addresses', 'users.id', '=', 'addresses.user_id')->get();
=> Illuminate\Database\Eloquent\Collection {#2346
     all: [
       App\User {#2307
         id: 1,
         name: "山本 七夏",
         email: "hirokawa.osamu@example.org",
         created_at: "2019-01-19 02:33:51",
         updated_at: "2019-01-19 02:33:51",
         user_id: 1,
         type: "自宅",
         address: "5212837  京都府佐々木市西区近藤町加納9-4-4 コーポ宮沢110号",
       },
       App\User {#2353
         id: 2,
         name: "若松 裕樹",
         email: "tsuda.rika@example.com",
         created_at: "2019-01-19 02:33:51",
         updated_at: "2019-01-19 02:33:51",
         user_id: 2,
         type: "自宅",
         address: "4853444  奈良県佐々木市南区鈴木町廣川8-3-9",
       },
       App\User {#2355
         id: 3,
         name: "江古田 裕太",
         email: "ksato@example.org",
         created_at: "2019-01-19 02:33:51",
         updated_at: "2019-01-19 02:33:51",
         user_id: 3,
         type: "会社",
         address: "8386040  愛知県宮沢市中央区井高町加納4-2-10",
       },
     ],
   }

うまくフェイクデータが作成されましたね。

最後に１つ有用なコマンドとして、migrate:status。現在のmigrationのステータスを一覧できます。左の1列目がすべてＹとなっているのは現在あるmigrationがすべて実行された状態です。

$ php artisan migrate:status
+------+------------------------------------------------+
| Ran? | Migration                                      |
+------+------------------------------------------------+
| Y    | 2014_10_12_000000_create_users_table           |
| Y    | 2014_10_12_100000_create_password_resets_table |
| Y    | 2019_01_10_140631_create_addresses_table       |
| Y    | 2019_01_15_132109_change_addresses_table       |
| Y    | 2019_01_18_131940_change_addresses2_table      |
+------+------------------------------------------------+

migrate:rollbackしたなら、すべてNoのＮとなります。

+------+------------------------------------------------+
| Ran? | Migration                                      |
+------+------------------------------------------------+
| N    | 2014_10_12_000000_create_users_table           |
| N    | 2014_10_12_100000_create_password_resets_table |
| N    | 2019_01_10_140631_create_addresses_table       |
| N    | 2019_01_15_132109_change_addresses_table       |
| N    | 2019_01_18_131940_change_addresses2_table      |
+------+------------------------------------------------+

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