Laravel – アップロードファイルの取得

2021-10-18 / tau / コメントする

概要

ファイル選択要素を持つフォームでファイルを取得する手順を整理する。概要は以下のような流れ。

ファイル選択要素を持ったフォームを含むページを表示する
ユーザーがファイルを選択してPOSTリクエスト
リクエストを介して、サーバーにアップロード・一時保存されたファイルを取得する
バリデーションが必要な場合、フォームリクエストを作成して実装

基本例

機能

アップロードファイル取得の機能を、シンプルなコントローラーとビューで確認する。例として、画像ファイルの取得を目的として組み立てていく。

ファイル取得に限って言えば、要点は次の2点。

ビューでは、ファイル選択要素を持つフォームでファイルを選択、送信
コントローラーでは、アップロードされたファイルをフォームのリクエストから取得

ルーティング

例として以下のようにルーティングを設定する。

Route::resource('images', 'ImageController')
  ->only(['index', 'store']);

1 2	Route::resource('images', 'ImageController') ->only(['index', 'store']);

設定されるルーティングは以下のとおり。

$ php artisan route:list
+--------+----------+--------+----------------+--------------------------------------------+------------+
| Domain | Method   | URI    | Name           | Action                                     | Middleware |
+--------+----------+--------+----------------+--------------------------------------------+------------+
........
|        | GET|HEAD | images | images.index   | App\Http\Controllers\ImageController@index | web        |
|        | POST     | images | images.store   | App\Http\Controllers\ImageController@store | web        |
........
+--------+----------+--------+----------------+--------------------------------------------+------------+

$ php artisan route:list

+--------+----------+--------+----------------+--------------------------------------------+------------+

+--------+----------+--------+----------------+--------------------------------------------+------------+

........

........

+--------+----------+--------+----------------+--------------------------------------------+------------+

/imagesへのGETリクエストでコントローラーのindexアクションが呼ばれる
- このアクションでフォームページを表示する
フォームからのPOSTリクエストは/imagesに送られ、コントローラーのstoreアクションが呼ばれる
- 本来はファイル保存を想定したアクションだが、ここではファイルの内容確認のみ行う

コントローラー～フォーム表示

indexアクションではフォームを含むページを表示するだけ。

class ImageController extends Controller
{
    ........
    public function index() {
        return view('images.index');
    }
    ........
}

class ImageController extends Controller

{

........

public function index() {

return view('images.index');

}

........

}

ビュー～フォームとファイル選択要素の設定

表示するページのテンプレートは以下の通りで以下の2点が要点。

FORM要素でenctype="multipart/form-data"を指定している
INPUT要素でtype="file"としている

HTML-input-fileを参照

<!DOCTYPE html>
<html lang="ja">
  <head>
    <meta charset="utf-8">
    <title>画像ファイル選択</title>
  </head>
  <body>
    <h1>画像ファイル選択</h1>
    <form method="post" action="{{ route('images.store') }}" enctype="multipart/form-data">
      @csrf
      <input type="file" name="image">
      <input type="submit" value="送信">
    </form>
  </body>
</html>

<!DOCTYPE html>

<head>

<title>画像ファイル選択</title>

</head>

<body>

<h1>画像ファイル選択</h1>

@csrf

</form>

</body>

</html>

フォームで選択されたファイルの取得

アップロードされたファイルは、メソッド・インジェクションで得られたRequestオブジェクトのfile()メソッドで得られる。file()メソッドの引数にINPUT要素のname属性値を指定することでファイルのオブジェクトを得られる。

以下のアクションでは選択されたファイルの内容をdd()で表示させ、そこで実行を止めている。

class ImageController extends Controller
{
    ........
    public function store(Request $request) {
      $image = $request->file('image');
      dd($image);
    }
    ........
}

class ImageController extends Controller

{

........

public function store(Request $request) {

$image = $request->file('image');

dd($image);

}

........

}

ローカルのファイルを選択して送信ボタンを押した結果、上記のdd()で表示された内容を示したのが下記。この例ではJPEGファイルをアップロードしている。

アップロードされたファイルの実体が一時的に保存されるのは/tmpディレクトリーで、php.iniのupload_tmp_dirで設定されるようだが、コメントアウトされていた。この場合はルート直下の/tmpになると思われる。

Illuminate\Http\UploadedFile {#1244 ▼
  -test: false
  -originalName: "18420_smile1.jpg"
  -mimeType: "image/jpeg"
  -error: 0
  #hashName: null
  path: "/tmp"
  filename: "phpEyN1ug"
  basename: "phpEyN1ug"
  pathname: "/tmp/phpEyN1ug"
  extension: ""
  realPath: "/tmp/phpEyN1ug"
  aTime: 2021-10-17 19:22:08
  mTime: 2021-10-17 19:22:08
  cTime: 2021-10-17 19:22:08
  inode: 67201770
  size: 604673
  perms: 0100600
  owner: 1000
  group: 1000
  type: "file"
  writable: true
  readable: true
  executable: false
  file: true
  dir: false
  link: false
}

Illuminate\Http\UploadedFile {#1244 ▼

-test: false

-originalName: "18420_smile1.jpg"

-mimeType: "image/jpeg"

-error: 0

#hashName: null

path: "/tmp"

filename: "phpEyN1ug"

basename: "phpEyN1ug"

pathname: "/tmp/phpEyN1ug"

extension: ""

realPath: "/tmp/phpEyN1ug"

aTime: 2021-10-17 19:22:08

mTime: 2021-10-17 19:22:08

cTime: 2021-10-17 19:22:08

inode: 67201770

size: 604673

perms: 0100600

owner: 1000

group: 1000

type: "file"

writable: true

readable: true

executable: false

file: true

dir: false

link: false

}

バリデーション

フォームリクエスト

フォーム入力からファイルアップロード時にバリデーションをかける場合、フォームリクエストを使うとコントローラーで行うよりも明快になる。

フォームリクエストはartisanで作成する。

$ php artisan make:request ImageRequest
Request created successfully.

1 2	$ php artisan make:request ImageRequest Request created successfully.

フォームリクエストファイルはapp/Http/Requestsディレクトリーに作成され、このファイルにバリデーションの条件を記述する。条件は配列で書くか、文字列内で'|'で連結してもよい。

フォームリクエスト生成時にはauthorize()の戻り値はfalseになっているが、ここでは無条件にtrueとしている。

?php

namespace App\Http\Requests;

use Illuminate\Foundation\Http\FormRequest;

class ImageRequest extends FormRequest
{
    public function authorize()
    {
        return true;
    }

    public function rules()
    {
        return [
            'image' => [
                // ファイルがアップロードされている
                'file',
                // ファイル形式がJPEGかPNG
                'mimes:jpeg,jpg,png',
                // 画像のサイズ
                'dimensions:min_width=100,min_height=100,max_width=500,max_height=500',
            ],
        ];
    }
}

?php

namespace App\Http\Requests;

use Illuminate\Foundation\Http\FormRequest;

class ImageRequest extends FormRequest

{

public function authorize()

{

return true;

}

public function rules()

{

return [

'image' => [

// ファイルがアップロードされている

'file',

// ファイル形式がJPEGかPNG

'mimes:jpeg,jpg,png',

// 画像のサイズ

'dimensions:min_width=100,min_height=100,max_width=500,max_height=500',

];

}

ここでは画像ファイルを想定したバリデーションをかけているが、画像以外のファイルを扱う場合は、MIMEタイプをpdfやdocなど様々なファイル形式で指定。

また、ファイルサイズをmax:xxxのようにKB単位で制限することもできる。

なおここではファイルがアップロードされていないときは$imageはnullとなるが、ファイル指定を必須とする場合はrequiredを指定し、エラーメッセージでファイル指定を促すなどの対応をする。

エラー表示

フォームリクエストでのバリデーションの結果エラーがあると、検証結果が$errorsに記録され、もとのビューにリダイレクトされる。

ここでは、以下のようにフォーム入力のテンプレートで@foreachを使って$errorsの内容を全て表示させている。$errorsの使い方についてはこちらを参照。

<!DOCTYPE html>
<html lang="ja" dir="ltr">
  <head>
    <meta charset="utf-8">
    <title>画像選択</title>
  </head>
  <body>
    <h1>画像選択</h1>
    <form method="post" action="{{ route('images.store') }}" enctype="multipart/form-data">
      @csrf
      <input type="file" name="image">
      <input type="submit" value="登録">
    </form>

    {{-- バリデーションエラー表示 --}}
    @foreach ($errors->all() as $error)
      <p>{{ $error }}</p>
    @endforeach
  </body>
</html>

<!DOCTYPE html>

<head>

</head>

<body>

@csrf

</form>

@foreach ($errors->all() as $error)

<p>{{ $error }}</p>

@endforeach

</body>

</html>

Laravel – リレーション

2021-10-12 / tau / コメントする

概要

Laravelでは、テーブル間のリレーションを設定することで、外部キーで関連付けられた複数のモデルを(外部キーを意識することなく)一貫して扱うことができる。

リレーションの種類と定義方法

リレーションはモデル定義で設定し、以下の3種類の何れかを設定する。

hasOne: 1対1のリレーションの親のモデルで設定し、親データに属する子データのモデルとidを指定する。これにより親データから子データやそのプロパティーの参照が可能になる。
hasMany: 1対nの親のモデルで設定し、親データに属する子データのモデルとidを指定する。これにより親データから子データのコレクション、要素インスタンスやそのプロパティーの参照が可能になる。
belongsTo: 1対1、1対nとも子のモデルで設定し、子データが属する親データを指す外部キーと親のモデルを指定する。これにより子データから親データやそのプロパティーが参照可能になる。

いずれについてもモデルでの記述方法は同じで、たとえばhasManyを例にとると以下の様に書く。

class 親のモデル extends Model {
  public function 子の参照名() {
    return $this->hasMany('App\子のモデル');
  }
}

class 親のモデル extends Model {

public function 子の参照名() {

return $this->hasMany('App\子のモデル');

}

子の参照名はモデル名のスモールケースで、hasOneの場合は単数形、hasManyの場合は複数形。

例えば親テーブルcustomersのデータが子テーブルemailsのデータを1つだけ持つ場合は以下の様に書く。

class Customer extends Model {
  public function email() {
    return $this->hasOne('App\Email');
  }
}

class Customer extends Model {

public function email() {

return $this->hasOne('App\Email');

}

また、親テーブルcustomersのデータが子テーブルordersの複数のデータを持つ場合は以下の様に書く。

class Customer extends Model {
  public function orders() {
    return $this->hasMany('App\Order');
  }
}

class Customer extends Model {

public function orders() {

return $this->hasMany('App\Order');

}

子テーブルのデータが親テーブルのデータに属することを設定するbelongsToでは、メソッド名は単数形。

class Email extends Model
{
    public function customer() {
        return $this->belongsTo('App\Customer');
    }
}

class Order extends Model
{
    public function customer() {
        return $this->belongsTo('App\Customer');
    }
}

class Email extends Model

{

public function customer() {

return $this->belongsTo('App\Customer');

}

class Order extends Model

{

public function customer() {

return $this->belongsTo('App\Customer');

}

リレーション設定後の参照方法

リレーションを設定すると、そのメソッド名と同じ名前のプロパティーによって親から子、子から親のモデルインスタンスを参照できるようになる。

先のCustomer、Email、Orderの場合、以下の様に参照する。

$customer->email
// その顧客のemailアドレスがEmailインスタンスで得られる

$customer->orders
// その顧客の注文品群がOrderインスタンスの配列で得られる

$email->customer
// そのemailを持つCustomerインスタンスが得られる

$email->customer
// その注文をしたCustomerインスタンスが得られる

$customer->email

// その顧客のemailアドレスがEmailインスタンスで得られる

$customer->orders

// その顧客の注文品群がOrderインスタンスの配列で得られる

$email->customer

// そのemailを持つCustomerインスタンスが得られる

$email->customer

// その注文をしたCustomerインスタンスが得られる

子データが得られれば、以下の例の様にそのプロパティーも得ることができる。

$customer->email->email;
// 顧客のEmailデータのemailプロパティー

$customer->orders[0]->item;
// 顧客の最初の注文データの注文品名

$order->customer->name;
// 注文した顧客の名前

$customer->email->email;

// 顧客のEmailデータのemailプロパティー

$customer->orders[0]->item;

// 顧客の最初の注文データの注文品名

$order->customer->name;

// 注文した顧客の名前

挙動確認

準備

設定

挙動確認のため、3つのモデルとテーブルを作成する。

Customer
- Auto Increment(AI)のid、顧客名、作成・更新日時を持つ
- e-mailアドレスを1つだけ持つ
- 複数の注文を持つ
Email
- AIのid、e-mailアドレスを持つ顧客のid、アドレス、作成・更新日時を持つ
Order
- AIのid、注文した顧客のid、注文品、作成・更新日時を持つ

モデル作成

artisanでCustomer、Email、Orderの3つのモデルを、マイグレーションファイルとともに作成する。

$ php artisan make:model Customer --migration
Model created successfully.
Created Migration: 2021_10_11_203918_create_customers_table
$ php artisan make:model Email --migration
Model created successfully.
Created Migration: 2021_10_11_203937_create_emails_table
$ php artisan make:model Order --migration
Model created successfully.
Created Migration: 2021_10_11_203951_create_orders_table

$ php artisan make:model Customer --migration

Model created successfully.

Created Migration: 2021_10_11_203918_create_customers_table

$ php artisan make:model Email --migration

Model created successfully.

Created Migration: 2021_10_11_203937_create_emails_table

$ php artisan make:model Order --migration

Model created successfully.

Created Migration: 2021_10_11_203951_create_orders_table

timestampsの生成の抑制

本筋ではないが、ここではテーブル構造をシンプルにするため、デフォルトのtimestampsの生成を抑制している。

マイグレーションファイル編集

マイグレーションファイルを編集し、各テーブルの要素を追加する。なおタイムスタンプを省略するため、各マイグレーションファイルに自動で記述される$table->timestamps()は削除している。

customersテーブルには顧客名を追加記述する。

class CreateCustomersTable extends Migration
{
    public function up()
    {
        Schema::create('customers', function (Blueprint $table) {
            $table->bigIncrements('id');

            // 顧客名
            $table->string('name');
        });
    }
    ........
}

class CreateCustomersTable extends Migration

{

public function up()

{

Schema::create('customers', function (Blueprint $table) {

$table->bigIncrements('id');

// 顧客名

$table->string('name');

});

}

........

}

emailsテーブルには以下を追加記述する。

親のcustomersテーブルのidを参照する外部キーcustomer_idと、メールアドレスemail
customer_idの外部キー設定

class CreateEmailsTable extends Migration
{
    public function up()
    {
        Schema::create('emails', function (Blueprint $table) {
            $table->bigIncrements('id');

            // メールアドレスを持っている顧客ID
            $table->unsignedBigInteger('customer_id');
            // メールアドレス
            $table->string('email');

            // 外部キー設定
            $table->foreign('customer_id')->references('id')->on('customers')
                  ->onDelete('cascade')->onUpdate('cascade');
        });
    }
    ........
}

class CreateEmailsTable extends Migration

{

public function up()

{

Schema::create('emails', function (Blueprint $table) {

$table->bigIncrements('id');

// メールアドレスを持っている顧客ID

$table->unsignedBigInteger('customer_id');

// メールアドレス

$table->string('email');

// 外部キー設定

$table->foreign('customer_id')->references('id')->on('customers')

->onDelete('cascade')->onUpdate('cascade');

});

}

........

}

ordersには以下を追加記述する。

親のcustomersテーブルのidを参照する外部キーcustomer_idと、注文品名item
customer_idの外部キー設定

class CreateOrdersTable extends Migration
{
    public function up()
    {
        Schema::create('orders', function (Blueprint $table) {
            $table->bigIncrements('id');

            // 注文主の顧客ID
            $table->unsignedBigInteger('customer_id');
            // 注文品名
            $table->string('item');

            // 外部キー設定
            $table->foreign('customer_id')->references('id')->on('customers')
                  ->onDelete('cascade')->onUpdate('cascade');
        });
    }
    ........
}

class CreateOrdersTable extends Migration

{

public function up()

{

Schema::create('orders', function (Blueprint $table) {

$table->bigIncrements('id');

// 注文主の顧客ID

$table->unsignedBigInteger('customer_id');

// 注文品名

$table->string('item');

// 外部キー設定

$table->foreign('customer_id')->references('id')->on('customers')

->onDelete('cascade')->onUpdate('cascade');

});

}

........

}

マイグレーション

マイグレーションを実行する。

$ php artisan migrate
Migrating: 2021_10_11_203918_create_customers_table
Migrated:  2021_10_11_203918_create_customers_table (0.01 seconds)
Migrating: 2021_10_11_203937_create_emails_table
Migrated:  2021_10_11_203937_create_emails_table (0.04 seconds)
Migrating: 2021_10_11_203951_create_orders_table
Migrated:  2021_10_11_203951_create_orders_table (0.04 seconds)

$ php artisan migrate

Migrating: 2021_10_11_203918_create_customers_table

Migrated: 2021_10_11_203918_create_customers_table (0.01 seconds)

Migrating: 2021_10_11_203937_create_emails_table

Migrated: 2021_10_11_203937_create_emails_table (0.04 seconds)

Migrating: 2021_10_11_203951_create_orders_table

Migrated: 2021_10_11_203951_create_orders_table (0.04 seconds)

テーブル構造

生成された3つのテーブルは以下のとおり。

customersテーブル

mysql> DESCRIBE customers;
+-------+-----------------+------+-----+---------+----------------+
| Field | Type            | Null | Key | Default | Extra          |
+-------+-----------------+------+-----+---------+----------------+
| id    | bigint unsigned | NO   | PRI | NULL    | auto_increment |
| name  | varchar(255)    | NO   |     | NULL    |                |
+-------+-----------------+------+-----+---------+----------------+
2 rows in set (0.00 sec)

mysql> DESCRIBE customers;

+-------+-----------------+------+-----+---------+----------------+

+-------+-----------------+------+-----+---------+----------------+

| id | bigint unsigned | NO | PRI | NULL | auto_increment |

+-------+-----------------+------+-----+---------+----------------+

2 rows in set (0.00 sec)

emailsテーブル。

mysql> DESCRIBE emails;
+-------------+-----------------+------+-----+---------+----------------+
| Field       | Type            | Null | Key | Default | Extra          |
+-------------+-----------------+------+-----+---------+----------------+
| id          | bigint unsigned | NO   | PRI | NULL    | auto_increment |
| customer_id | bigint unsigned | NO   | MUL | NULL    |                |
| email       | varchar(255)    | NO   |     | NULL    |                |
+-------------+-----------------+------+-----+---------+----------------+
3 rows in set (0.00 sec)

mysql> DESCRIBE emails;

+-------------+-----------------+------+-----+---------+----------------+

+-------------+-----------------+------+-----+---------+----------------+

| id | bigint unsigned | NO | PRI | NULL | auto_increment |

+-------------+-----------------+------+-----+---------+----------------+

3 rows in set (0.00 sec)

ordersテーブル。

mysql> DESCRIBE orders;
+-------------+-----------------+------+-----+---------+----------------+
| Field       | Type            | Null | Key | Default | Extra          |
+-------------+-----------------+------+-----+---------+----------------+
| id          | bigint unsigned | NO   | PRI | NULL    | auto_increment |
| customer_id | bigint unsigned | NO   | MUL | NULL    |                |
| item        | varchar(255)    | NO   |     | NULL    |                |
+-------------+-----------------+------+-----+---------+----------------+
3 rows in set (0.00 sec)

mysql> DESCRIBE orders;

+-------------+-----------------+------+-----+---------+----------------+

+-------------+-----------------+------+-----+---------+----------------+

| id | bigint unsigned | NO | PRI | NULL | auto_increment |

+-------------+-----------------+------+-----+---------+----------------+

3 rows in set (0.00 sec)

リレーション設定

リレーションを各モデルで設定する。なおタイムスタンプを省略するため、各モデルで$timestampsをfalseにセットする行を追加している。

Customerモデルでは、1対1でEmailを子に持つこと、1対nでOrderを子に持つことを設定。

class Customer extends Model
{
    public $timestamps = false;

    public function email() {
        return $this->hasOne('App\Email');
    }

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

class Customer extends Model

{

public $timestamps = false;

public function email() {

return $this->hasOne('App\Email');

}

public function orders() {

return $this->hasMany('App\Order');

}

EmailモデルではCustomerを親に持つことを設定。

class Email extends Model
{
    public $timestamps = false;

    public function customer() {
        return $this->belongsTo('App\Customer');
    }
}

class Email extends Model

{

public $timestamps = false;

public function customer() {

return $this->belongsTo('App\Customer');

}

OrderモデルではCustomerを親に持つことを設定。

class Order extends Model
{
    public $timestamps = false;

    public function customer() {
        return $this->belongsTo('App\Customer');
    }
}

class Order extends Model

{

public $timestamps = false;

public function customer() {

return $this->belongsTo('App\Customer');

}

テストデータ作成

tinkerでテストデータを作成し、データベースに登録する。

Customer

まずCustomerのデータを登録する。

$ php artisan tinker
Psy Shell v0.10.8 (PHP 7.3.29 — cli) by Justin Hileman
>>> $customer = new Customer();
[!] Aliasing 'Customer' to 'App\Customer' for this Tinker session.
=> App\Customer {#3380}
>>> $customer->name = 'customer1';
=> "customer1"
>>> $customer->save();
=> true
........

$ php artisan tinker

Psy Shell v0.10.8 (PHP 7.3.29 — cli) by Justin Hileman

>>> $customer = new Customer();

[!] Aliasing 'Customer' to 'App\Customer' for this Tinker session.

=> App\Customer {#3380}

>>> $customer->name = 'customer1';

=> "customer1"

>>> $customer->save();

=> true

........

3人の顧客データを登録。

mysql> SELECT * FROM customers;
+----+-----------+
| id | name      |
+----+-----------+
|  1 | customer1 |
|  2 | customer2 |
|  3 | customer3 |
+----+-----------+
3 rows in set (0.00 sec)

mysql> SELECT * FROM customers;

+----+-----------+

| id | name |

+----+-----------+

| 1 | customer1 |

| 2 | customer2 |

| 3 | customer3 |

+----+-----------+

3 rows in set (0.00 sec)

Email

Emailのデータを、Customerの各データに関連付けながら登録する。ここではcustomer1とcustomer2に紐づくデータを登録し、customer3のアドレスは未登録とする。

>>> $email = new Email();
[!] Aliasing 'Email' to 'App\Email' for this Tinker session.
=> App\Email {#4101}
>>> $email->customer_id = 1;
=> 1
>>> $email->email = 'customer1@mail.com';
=> "customer1@mail.com"
>>> $email->save();
=> true
........

>>> $email = new Email();

[!] Aliasing 'Email' to 'App\Email' for this Tinker session.

=> App\Email {#4101}

>>> $email->customer_id = 1;

=> 1

>>> $email->email = 'customer1@mail.com';

=> "customer1@mail.com"

>>> $email->save();

=> true

........

登録後のテーブルは以下のとおり。

mysql> SELECT * FROM emails;
+----+-------------+--------------------+
| id | customer_id | email              |
+----+-------------+--------------------+
|  1 |           1 | customer1@mail.com |
|  2 |           2 | customer2@mail.com |
+----+-------------+--------------------+
2 rows in set (0.00 sec)

mysql> SELECT * FROM emails;

+----+-------------+--------------------+

| id | customer_id | email |

+----+-------------+--------------------+

| 1 | 1 | customer1@mail.com |

| 2 | 2 | customer2@mail.com |

+----+-------------+--------------------+

2 rows in set (0.00 sec)

Order

Orderのデータを、Customerの各データに関連付けながら登録する。ここではcustomer1に1つの、customer2に2つの注文があり、customer3からの注文はない状態とする。

>>> $order = new Order();
[!] Aliasing 'Order' to 'App\Order' for this Tinker session.
=> App\Order {#4313}
>>> $order->id = 1;
=> 1
>>> $order->customer_id = 1;
=> 1
>>> $order->item = 'screw';
=> "screw"
>>> $order->save();
=> true
........

>>> $order = new Order();

[!] Aliasing 'Order' to 'App\Order' for this Tinker session.

=> App\Order {#4313}

>>> $order->id = 1;

=> 1

>>> $order->customer_id = 1;

=> 1

>>> $order->item = 'screw';

=> "screw"

>>> $order->save();

=> true

........

登録後のテーブルは以下のとおりで、customer1はネジのオーダー1つ、customer2はゴムシートとプラスチック板で2つのオーダー。

mysql> SELECT * FROM orders;
+----+-------------+---------------+
| id | customer_id | item          |
+----+-------------+---------------+
|  1 |           1 | screw         |
|  2 |           2 | rubber sheet  |
|  3 |           2 | plastic plate |
+----+-------------+---------------+
3 rows in set (0.00 sec)

mysql> SELECT * FROM orders;

+----+-------------+---------------+

| id | customer_id | item |

+----+-------------+---------------+

| 1 | 1 | screw |

| 2 | 2 | rubber sheet |

| 3 | 2 | plastic plate |

+----+-------------+---------------+

3 rows in set (0.00 sec)

リレーションを使った操作

親データを取得

まず3人の顧客のデータを取得する。

>>> $customer1 = Customer::find(1);
=> App\Customer {#4322
     id: 1,
     name: "customer1",
   }
>>> $customer2 = Customer::find(2);
=> App\Customer {#4315
     id: 2,
     name: "customer2",
   }
>>> $customer3 = Customer::find(3);
=> App\Customer {#4323
     id: 3,
     name: "customer3",
   }

>>> $customer1 = Customer::find(1);

=> App\Customer {#4322

id: 1,

}

>>> $customer2 = Customer::find(2);

=> App\Customer {#4315

id: 2,

}

>>> $customer3 = Customer::find(3);

=> App\Customer {#4323

id: 3,

}

親からhasOneを取得

それぞれの顧客データから、hasOneで関連付けられたemailのインスタンスを取得する。$customer3のemailは未登録なのでnullとなる。

>>> $customer1->email;
=> App\Email {#4328
     id: 1,
     customer_id: 1,
     email: "customer1@mail.com",
   }
>>> $customer2->email;
=> App\Email {#4329
     id: 2,
     customer_id: 2,
     email: "customer2@mail.com",
   }
>>> $customer3->email;
=> null

>>> $customer1->email;

=> App\Email {#4328

id: 1,

customer_id: 1,

email: "customer1@mail.com",

}

>>> $customer2->email;

=> App\Email {#4329

id: 2,

customer_id: 2,

email: "customer2@mail.com",

}

>>> $customer3->email;

=> null

親からhasManyを取得

それぞれの顧客データから、hasManyで関連付けられたorderのデータを取得する。

hasManyリレーションのデータは配列で得られる
データが1つの場合は要素数1の配列
子データがない場合は空の配列

>>> $customer1->orders;
=> Illuminate\Database\Eloquent\Collection {#4335
     all: [
       App\Order {#4333
         id: 1,
         customer_id: 1,
         item: "screw",
       },
     ],
   }
>>> $customer2->orders;
=> Illuminate\Database\Eloquent\Collection {#4324
     all: [
       App\Order {#4338
         id: 2,
         customer_id: 2,
         item: "rubber sheet",
       },
       App\Order {#4341
         id: 3,
         customer_id: 2,
         item: "plastic plate",
       },
     ],
   }
>>> $customer3->orders;
=> Illuminate\Database\Eloquent\Collection {#4344
     all: [],
   }

>>> $customer1->orders;

=> Illuminate\Database\Eloquent\Collection {#4335

all: [

App\Order {#4333

id: 1,

customer_id: 1,

item: "screw",

}

>>> $customer2->orders;

=> Illuminate\Database\Eloquent\Collection {#4324

all: [

App\Order {#4338

id: 2,

customer_id: 2,

item: "rubber sheet",

App\Order {#4341

id: 3,

customer_id: 2,

item: "plastic plate",

}

>>> $customer3->orders;

=> Illuminate\Database\Eloquent\Collection {#4344

all: [],

}

hasManyの場合、子データは配列で得られるので、要素指定やforeachなどで個々のデータを取り出す。

>>> $customer1->orders[0]
=> App\Order {#4333
     id: 1,
     customer_id: 1,
     item: "screw",
   }

>>> $customer1->orders[0]

=> App\Order {#4333

id: 1,

customer_id: 1,

item: "screw",

}

子データのプロパティーの取得

hasOneやhasManyの子データが親データから得られれば、そのプロパティーを得ることもできる。

>>> $customer1->orders[0]->item;
=> "screw"

1 2	>>> $customer1->orders[0]->item; => "screw"

hasOneの子から親を取得

hasOneのEmailが属するCustomerを取得する例。ここでは変数を介さず、生成したインスタンスから直接プロパティーを参照している。

>>> Email::find(1)->customer;
=> App\Customer {#4346
     id: 1,
     name: "customer1",
   }
>>> Email::find(2)->customer;
=> App\Customer {#4349
     id: 2,
     name: "customer2",
   }

>>> Email::find(1)->customer;

=> App\Customer {#4346

id: 1,

}

>>> Email::find(2)->customer;

=> App\Customer {#4349

id: 2,

}

hasManyの子から親を取得

hasManyで関連付けられた子のOrderから親のCustomerを取得する例。

>>> Order::find(1)->customer;
=> App\Customer {#4350
     id: 1,
     name: "customer1",
   }
>>> Order::find(2)->customer;
=> App\Customer {#4352
     id: 2,
     name: "customer2",
   }
>>> Order::find(3)->customer;
=> App\Customer {#4354
     id: 2,
     name: "customer2",
   }

>>> Order::find(1)->customer;

=> App\Customer {#4350

id: 1,

}

>>> Order::find(2)->customer;

=> App\Customer {#4352

id: 2,

}

>>> Order::find(3)->customer;

=> App\Customer {#4354

id: 2,

}

親データのプロパティーの取得

子データから親データが得られれば、そのプロパティーも得ることができる。

>>> Email::find(1)->customer->name;
=> "customer1"

1 2	>>> Email::find(1)->customer->name; => "customer1"

Laravel – timestampsを抑制する

2021-10-11 / tau / コメントする

概要

Laraveのデフォルトでモデルとマイグレーションファイルを作成すると、マイグレーションファイルには$table->timestampsが自動的に記述され、マイグレートするとcreated_at、updated_atの2つのカラムがtimestamp型で定義される。

ここでは、これらのタイムスタンプを生成させない方法をまとめる。

マイグレーションファイルの該当文を削除orコメントアウト
モデルでタイムスタンプを生成させないよう記述を追加

マイグレーションファイルの編集

マイグレーションファイル生成時に自動で記述される$table->timestamps()を削除するかコメントアウトする。

class CreateTestModelsTable extends Migration
{
    public function up()
    {
        Schema::create('test_models', function (Blueprint $table) {
            $table->bigIncrements('id');
            $table->string('product_name', 20);
            $table->integer('amount');
            // $table-timestamps(); →削除してもよい
        });
    }
    ........
}

class CreateTestModelsTable extends Migration

{

public function up()

{

Schema::create('test_models', function (Blueprint $table) {

$table->bigIncrements('id');

$table->string('product_name', 20);

$table->integer('amount');

// $table-timestamps(); →削除してもよい

});

}

........

}

モデルへのタイムスタンプ抑制の記述

マイグレーションファイルからタイムスタンプの行を消しても、モデルをデータベースに登録しようとするとモデル側でタイムスタンプを生成し、データベースに対応するカラムがないとしてエラーになる。

そこで、モデルにタイムスタンプの生成を抑制する記述を追加する。

class TestModel extends Model
{
    public $timestamps = false;
}

class TestModel extends Model

{

public $timestamps = false;

}

Laravel – timestampsの2038年問題

2021-10-11 / tau / コメントする

マイグレーションファイルでのtimestamp

Laravelでマイグレーションファイルを生成させると、timestampが自動的に設定されている。たとえばusersテーブルを生成するマイグレーションファイルは以下のとおり。

class CreateUsersTable extends Migration
{
    .....
    public function up()
    {
        Schema::create('users', function (Blueprint $table) {
            $table->bigIncrements('id');
            $table->string('name');
            $table->string('email')->unique();
            $table->timestamp('email_verified_at')->nullable();
            $table->string('password');
            $table->rememberToken();
            $table->timestamps();
        });
    }
    .....
}

class CreateUsersTable extends Migration

{

.....

public function up()

{

Schema::create('users', function (Blueprint $table) {

$table->bigIncrements('id');

$table->string('name');

$table->string('email')->unique();

$table->timestamp('email_verified_at')->nullable();

$table->string('password');

$table->rememberToken();

$table->timestamps();

});

}

.....

}

生成されるテーブルの構造は以下のとおりで、引数を与えないtimestamps()メソッドはcreated_atとupdated_atの2つのカラムを生成する。

mysql> DESCRIBE users;
+-------------------+-----------------+------+-----+---------+----------------+
| Field             | Type            | Null | Key | Default | Extra          |
+-------------------+-----------------+------+-----+---------+----------------+
| id                | bigint 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    |                |
+-------------------+-----------------+------+-----+---------+----------------+
8 rows in set (0.00 sec)

mysql> DESCRIBE users;

+-------------------+-----------------+------+-----+---------+----------------+

+-------------------+-----------------+------+-----+---------+----------------+

| id | bigint unsigned | NO | PRI | NULL | auto_increment |

+-------------------+-----------------+------+-----+---------+----------------+

8 rows in set (0.00 sec)

ところがMySQLのtimestampは2038年問題を回避できないので、安易にこのまま使うののではなく、これらをdatetime型に変更しておいた方が安全。

timestamp	datetime
UTC内部表現で保持	タイムゾーン文字列で保持
1970-01-01 00:00:01UTC～2038-01-19 03:14:07UTC	1000-01-01 00:00:00～9999-12-31 23:59:59

マイグレーションファイルの修正

timestamps()を削除して、必要なら以下の2行に入れ替えるのが一方法。

class CreateUsersTable extends Migration
{
    /**
     * Run the migrations.
     *
     * @return void
     */
    public function up()
    {
        Schema::create('users', function (Blueprint $table) {
            $table->bigIncrements('id');
            $table->string('name');
            $table->string('email')->unique();
            //$table->timestamp('email_verified_at')->nullable();
            $table->datetime('email_verified_at')->nullable();
            $table->string('password');
            $table->rememberToken();
            //$table->timestamps();
            $table->datetime('created_at');
            $table->datetime('updated_at');
        });
    }

class CreateUsersTable extends Migration

{

/**

* Run the migrations.

* @return void

public function up()

{

Schema::create('users', function (Blueprint $table) {

$table->bigIncrements('id');

$table->string('name');

$table->string('email')->unique();

//$table->timestamp('email_verified_at')->nullable();

$table->datetime('email_verified_at')->nullable();

$table->string('password');

$table->rememberToken();

//$table->timestamps();

$table->datetime('created_at');

$table->datetime('updated_at');

});

}

このように設定すると、Laravelの方で作成日時と更新日時を自動的に更新してくれる(tinkerでのモデル操作を参照)。

Laravel – データ削除

2021-10-10 / tau / コメントする

delete～データの削除

データを削除するルーティングとしてdeleteが準備されている。

前提

モデルデータの操作で準備した枠組みを使う。ユーザー認証機能を持ち、ユーザーごとに入力されたシンプルな投稿記事Postを扱う。

流れ

DELETEメソッドでリクエスト
posts.deleteルートでPostsControllerのdestroyアクションを実行
destroyアクションで指定されたデータを削除

destroyアクションの呼び出し

リソースルーティングで以下のように設定されていて、DELETEメソッドによるリクエストの場合、ドメイン/posts/(id)からPostControllerのdestroyアクションにルーティングされる。ルーティング名はposts.delete。

$ php artisan route:list
+--------+-----------+------------------------+------------------+------------------------------------------------------------------------+--------------+
| Domain | Method    | URI                    | Name             | Action                                                                 | Middleware   |
+--------+-----------+------------------------+------------------+------------------------------------------------------------------------+--------------+
........
|        | POST      | posts                  | posts.store      | App\Http\Controllers\PostController@store                              | web,auth     |
|        | GET|HEAD  | posts                  | posts.index      | App\Http\Controllers\PostController@index                              | web,auth     |
|        | GET|HEAD  | posts/create           | posts.create     | App\Http\Controllers\PostController@create                             | web,auth     |
|        | GET|HEAD  | posts/{post}           | posts.show       | App\Http\Controllers\PostController@show                               | web,auth     |
|        | DELETE    | posts/{post}           | posts.destroy    | App\Http\Controllers\PostController@destroy                            | web,auth     |
|        | PUT|PATCH | posts/{post}           | posts.update     | App\Http\Controllers\PostController@update                             | web,auth     |
|        | GET|HEAD  | posts/{post}/edit      | posts.edit       | App\Http\Controllers\PostController@edit                               | web,auth     |
........

$ php artisan route:list

+--------+-----------+------------------------+------------------+------------------------------------------------------------------------+--------------+

+--------+-----------+------------------------+------------------+------------------------------------------------------------------------+--------------+

........

| | GET|HEAD | posts/{post} | posts.show | App\Http\Controllers\PostController@show | web,auth |

| | DELETE | posts/{post} | posts.destroy | App\Http\Controllers\PostController@destroy | web,auth |

| | PUT|PATCH | posts/{post} | posts.update | App\Http\Controllers\PostController@update | web,auth |

| | GET|HEAD | posts/{post}/edit | posts.edit | App\Http\Controllers\PostController@edit | web,auth |

........

このルーティングにリクエストする場合、たとえばページの中にフォーム要素とINPUT(type="submit")要素を配置することが考えられる。

ここでルーティングに従えばDELETEメソッドを明示する必要があるが、現在のブラウザーではGETとPOSTしか認識しない。

フォームからDELETEメソッドをリクエストする場合、以下のようにフォームのmethodではPOSTを指定し、Laravelの@methodディレクティブでDELETEを指定する。

@foreach ($posts as $post)
  <form class="delete" method="post" action="{{ route('posts.destroy', $post) }}">
    @csrf
    @method('delete')
    <input type="submit" value="削除">
  </form>
@endforeach

@foreach ($posts as $post)

@csrf

@method('delete')

</form>

@endforeach

この例では、フォームのaction先にroute()メソッドを使い、第一引数でposts.daestroyのルーティング名を、第2引数で削除対象のデータ$postを渡している。これによってDELETEメソッドでURIとしてドメイン名/posts/(id)が渡される

なお@methodディレクティブは、以下のようなhidden要素を生成する。

<input type="hidden" name="_method" value="delete">

1	<input type="hidden" name="_method" value="delete">

コントローラー～destroyアクション

ルーティングに従って、PostControllerのdestroyアクションを以下のように記述する。

class PostController extends Controller
{
    ........
    public function destroy($id)
    {
        $post = Post::find($id);
        $post->delete();
        return redirect()->route('posts.index');
    }
    ........
}

class PostController extends Controller

{

........

public function destroy($id)

{

$post = Post::find($id);

$post->delete();

return redirect()->route('posts.index');

}

........

}

ここでの要点は以下の通り。

destroy()メソッドの引数で、URLに埋め込まれたidが$idとして受け取られている
Postクラスのfind()メソッドの引数に$idを渡して、指定したidの記事インスタンスを$postで参照している
削除対象記事のインスタンス$postのdelete()メソッドの引数に、更新対象の要素を渡している
データ削除を反映した一覧表示のため、indexにリダイレクトしている

まとめ

以上の設定により、たとえばフォームに配置された削除ボタンを押すと、その記事のidがURLに埋め込まれてDELTEメソッドでリクエストされ、destroyアクションでデータが削除される。

Laravel – データ編集・更新

2021-10-10 / tau / コメントする

create, store～データの入力と登録

リソースルーティングでは、以下を意図している。

edit: データを編集する。フォームで編集する場合、フォームを持つビューを表示する。
update: 編集後の内容でデータベースのデータを更新する。editがフォームでの編集の場合、フォームのaction先をこのルートにする。

前提

モデルデータの操作で準備した枠組みを使う。ユーザー認証機能を持ち、ユーザーごとに入力されたシンプルな投稿記事Postを扱う。

流れ

編集する記事の$idを指定してドメイン名/posts/(id)/editをGETリクエスト
posts.editルートでPostsControllerのeditアクションを実行
editアクションで編集フォームを含むビューを表示
編集フォームのactionからposts.updateへルーティング
→methodはPATCH
posts.updateルートでPostControllerのupdateアクションを実行
updateアクションでデータベース上のデータを更新

editアクションの呼び出し

リソースルーティングで以下のように設定されていて、ドメイン/posts/(id)/editからPostControllerのeditアクションにルーティングされる。ルーティング名はposts.edit。

$ php artisan route:list
+--------+-----------+------------------------+------------------+------------------------------------------------------------------------+--------------+
| Domain | Method    | URI                    | Name             | Action                                                                 | Middleware   |
+--------+-----------+------------------------+------------------+------------------------------------------------------------------------+--------------+
........
|        | POST      | posts                  | posts.store      | App\Http\Controllers\PostController@store                              | web,auth     |
|        | GET|HEAD  | posts                  | posts.index      | App\Http\Controllers\PostController@index                              | web,auth     |
|        | GET|HEAD  | posts/create           | posts.create     | App\Http\Controllers\PostController@create                             | web,auth     |
|        | GET|HEAD  | posts/{post}           | posts.show       | App\Http\Controllers\PostController@show                               | web,auth     |
|        | DELETE    | posts/{post}           | posts.destroy    | App\Http\Controllers\PostController@destroy                            | web,auth     |
|        | PUT|PATCH | posts/{post}           | posts.update     | App\Http\Controllers\PostController@update                             | web,auth     |
|        | GET|HEAD  | posts/{post}/edit      | posts.edit       | App\Http\Controllers\PostController@edit                               | web,auth     |
........

$ php artisan route:list

+--------+-----------+------------------------+------------------+------------------------------------------------------------------------+--------------+

+--------+-----------+------------------------+------------------+------------------------------------------------------------------------+--------------+

........

| | GET|HEAD | posts/{post} | posts.show | App\Http\Controllers\PostController@show | web,auth |

| | DELETE | posts/{post} | posts.destroy | App\Http\Controllers\PostController@destroy | web,auth |

| | PUT|PATCH | posts/{post} | posts.update | App\Http\Controllers\PostController@update | web,auth |

| | GET|HEAD | posts/{post}/edit | posts.edit | App\Http\Controllers\PostController@edit | web,auth |

........

編集対象の記事を指定してposts.editにGETリクエストでルーティングする例として、以下のようなアンカー要素がある。

<a href="{{ route('posts.edit', $post) }}">編集</a>

1	<a href="{{ route('posts.edit', $post) }}">編集</a>

route()メソッドの第2引数でモデルデータを指定すると、自動的にルーティングに沿った形でデータのidがURLに埋め込まれる。

上記の例ではルーティングがposts.editでURLがposts/{post}/editとなっているので、例えば記事idが3の記事の場合は以下のようなURLとなり、これがブラウザーにも表示される。

ドメイン名/posts/3/edit

コントローラー～editアクション

コントローラーでは、ビューの$titleと編集対象の記事のインスタンスを設定してresources/views/posts/edit.blade.phpを表示させる。

editアクションに来る際にURLに埋め込まれたidが、editアクションメソッドの引数$idとして受け取られる。この$idをPostモデルのfind()メソッドの引数に与えて、指定したidの記事データを取得する。

class PostController extends Controller
{
    ........
    public function edit($id)
    {
      $post = Post::find($id);

      return view('posts.edit', [
        'title' => '投稿編集',
        'post' => $post,
      ]);
    }
    ........
}

class PostController extends Controller

{

........

public function edit($id)

{

$post = Post::find($id);

return view('posts.edit', [

'title' => '投稿編集',

'post' => $post,

]);

}

........

}

編集フォームビュー

bladeテンプレート

投稿を編集するフォームはposts/edit.blade.phpに以下の要領で記述。

ここでHTTPのメソッドはPOSTだが、ルーティングではPATCHメソッドを期待しているので、@method('patch')ディレクティブが必要。

  <form method="post" action="{{ route('posts.update', $post) }}">
    @csrf
    @method('patch')
    <div>
      <input type="text" name="comment" value="{{ $post->comment }}">
    </div>
    <input type="submit" value="更新">
  </form>

@csrf

@method('patch')

<div>

<input type="text" name="comment" value="{{ $post->comment }}">

</div>

</form>

actionで指定しているroute('posts.update', $post)はデータベースの更新アクションupdateへのルーティング。

PATCHに対するルーティングのURLはドメイン名/posts/(id)となる。

$ php artisan route:list
+--------+-----------+------------------------+------------------+------------------------------------------------------------------------+--------------+
| Domain | Method    | URI                    | Name             | Action                                                                 | Middleware   |
+--------+-----------+------------------------+------------------+------------------------------------------------------------------------+--------------+
........
|        | POST      | posts                  | posts.store      | App\Http\Controllers\PostController@store                              | web,auth     |
|        | GET|HEAD  | posts                  | posts.index      | App\Http\Controllers\PostController@index                              | web,auth     |
|        | GET|HEAD  | posts/create           | posts.create     | App\Http\Controllers\PostController@create                             | web,auth     |
|        | GET|HEAD  | posts/{post}           | posts.show       | App\Http\Controllers\PostController@show                               | web,auth     |
|        | DELETE    | posts/{post}           | posts.destroy    | App\Http\Controllers\PostController@destroy                            | web,auth     |
|        | PUT|PATCH | posts/{post}           | posts.update     | App\Http\Controllers\PostController@update                             | web,auth     |
|        | GET|HEAD  | posts/{post}/edit      | posts.edit       | App\Http\Controllers\PostController@edit                               | web,auth     |
........

$ php artisan route:list

+--------+-----------+------------------------+------------------+------------------------------------------------------------------------+--------------+

+--------+-----------+------------------------+------------------+------------------------------------------------------------------------+--------------+

........

| | GET|HEAD | posts/{post} | posts.show | App\Http\Controllers\PostController@show | web,auth |

| | DELETE | posts/{post} | posts.destroy | App\Http\Controllers\PostController@destroy | web,auth |

| | PUT|PATCH | posts/{post} | posts.update | App\Http\Controllers\PostController@update | web,auth |

| | GET|HEAD | posts/{post}/edit | posts.edit | App\Http\Controllers\PostController@edit | web,auth |

........

フォームリクエスト～バリデーション

編集フォームのバリデーションは入力フォームのところで作成したフォームリクエストを使う。

コントローラー～updateアクション

use指定

PostモデルとPostRequestに対するuse指定はフォーム入力で指定済み。

updateアクション

入力フォームのaction先で指定されたアクションメソッドで、編集後の内容でデータベースを更新する。

class PostController extends Controller
{
    ........
    public function update(PostRequest $request, $id)
    {
        // return 'update:' . $id;
        $post = Post::find($id);
        $post->update($request->only(['comment']));
        return redirect()->route('posts.index');
    }
    ........
}

class PostController extends Controller

{

........

public function update(PostRequest $request, $id)

{

// return 'update:' . $id;

$post = Post::find($id);

$post->update($request->only(['comment']));

return redirect()->route('posts.index');

}

........

}

ここでの要点は以下の通り。

フォームリクエストのバリデーションを有効にするため、update()メソッドのインジェクションをPostRequestにしている
update()メソッドの第2引数で、URLに埋め込まれたidが$idとして受け取られている
Postクラスのfind()メソッドの引数に$idを渡して、指定したidの記事インスタンスを$postで参照している
編集対象記事のインスタンス$postのupdate()メソッドの引数に、更新対象の要素を渡している
- 更新対象の要素は、引数のリクエストで得られたフォーム入力のcommentをonly()で限定している
更新後のデータを含めた一覧表示のため、indexにリダイレクトしている

モデルでの$fillable設定

update()メソッドでのフォームリクエストによる登録はマスアサインメントになるので、モデルに$fillableの定義が必要(フォーム入力のところで定義済み)。

確認

ユーザーログイン状態で<a href="{{ route('posts.edit', $post) }}">編集</a>などでGETリクエストすると編集フォームのページが表示され、更新ボタンを押すとデータが更新される。

mysql> SELECT * FROM posts;
+----+---------+-----------------------------------+---------------------+---------------------+
| id | user_id | comment                           | created_at          | updated_at          |
+----+---------+-----------------------------------+---------------------+---------------------+
|  1 |       1 | user1の1つ目の投稿を編集          | 2021-10-09 10:34:47 | 2021-10-10 11:40:44 |
|  2 |       1 | user1の2つ目の投稿                | 2021-10-09 10:35:01 | 2021-10-09 10:35:01 |
|  3 |       2 | user2の1つ目の投稿を編集          | 2021-10-09 10:35:32 | 2021-10-10 10:56:10 |
|  4 |       2 | user2の2つ目の投稿も編集          | 2021-10-09 10:35:45 | 2021-10-10 10:57:06 |
+----+---------+-----------------------------------+---------------------+---------------------+
4 rows in set (0.00 sec)

mysql> SELECT * FROM posts;

+----+---------+-----------------------------------+---------------------+---------------------+

+----+---------+-----------------------------------+---------------------+---------------------+

| 1 | 1 | user1の1つ目の投稿を編集 | 2021-10-09 10:34:47 | 2021-10-10 11:40:44 |

| 2 | 1 | user1の2つ目の投稿 | 2021-10-09 10:35:01 | 2021-10-09 10:35:01 |

| 3 | 2 | user2の1つ目の投稿を編集 | 2021-10-09 10:35:32 | 2021-10-10 10:56:10 |

| 4 | 2 | user2の2つ目の投稿も編集 | 2021-10-09 10:35:45 | 2021-10-10 10:57:06 |

+----+---------+-----------------------------------+---------------------+---------------------+

4 rows in set (0.00 sec)

Laravel – データ表示

2021-10-10 / tau / コメントする

index～全データ表示

データの一覧を表示させるルーティングとしてindexを使う。

前提

モデルデータの操作で準備した枠組みを使う。ユーザー認証機能を持ち、ユーザーごとに入力されたシンプルな投稿記事Postを扱う。

流れ

ドメイン名/postsをGETリクエスト
posts.indexルートでPostsControllerのindexアクションを実行
indexアクションでログインユーザーの投稿記事を表示

indexアクションの呼び出し

リソースルーティングで以下のように設定されていて、GETメソッドによるリクエストの場合、ドメイン/postsからPostControllerのindexアクションにルーティングされる。ルーティング名はposts。

$ php artisan route:list
+--------+-----------+------------------------+------------------+------------------------------------------------------------------------+--------------+
| Domain | Method    | URI                    | Name             | Action                                                                 | Middleware   |
+--------+-----------+------------------------+------------------+------------------------------------------------------------------------+--------------+
........
|        | POST      | posts                  | posts.store      | App\Http\Controllers\PostController@store                              | web,auth     |
|        | GET|HEAD  | posts                  | posts.index      | App\Http\Controllers\PostController@index                              | web,auth     |
|        | GET|HEAD  | posts/create           | posts.create     | App\Http\Controllers\PostController@create                             | web,auth     |
|        | GET|HEAD  | posts/{post}           | posts.show       | App\Http\Controllers\PostController@show                               | web,auth     |
|        | DELETE    | posts/{post}           | posts.destroy    | App\Http\Controllers\PostController@destroy                            | web,auth     |
|        | PUT|PATCH | posts/{post}           | posts.update     | App\Http\Controllers\PostController@update                             | web,auth     |
|        | GET|HEAD  | posts/{post}/edit      | posts.edit       | App\Http\Controllers\PostController@edit                               | web,auth     |
........

$ php artisan route:list

+--------+-----------+------------------------+------------------+------------------------------------------------------------------------+--------------+

+--------+-----------+------------------------+------------------+------------------------------------------------------------------------+--------------+

........

| | GET|HEAD | posts/{post} | posts.show | App\Http\Controllers\PostController@show | web,auth |

| | DELETE | posts/{post} | posts.destroy | App\Http\Controllers\PostController@destroy | web,auth |

| | PUT|PATCH | posts/{post} | posts.update | App\Http\Controllers\PostController@update | web,auth |

| | GET|HEAD | posts/{post}/edit | posts.edit | App\Http\Controllers\PostController@edit | web,auth |

........

コントローラー～indexアクション

ルーティングに従って、PostControllerのindexアクションを以下のように記述する。

class PostController extends Controller
{
    ........
    public function index()
    {
        $posts = Post::all();

        return view('posts.index', [
          'title' => '投稿一覧',
          'posts' => $posts,
        ]);
    }
    ........
}

class PostController extends Controller

{

........

public function index()

{

$posts = Post::all();

return view('posts.index', [

'title' => '投稿一覧',

'posts' => $posts,

]);

}

........

}

all()メソッドは、Postモデルのデータが保存されているpostsテーブルから全データを取得して配列として返す。つまりこの段階では、すべてのログインユーザーが他のユーザーのものも含めた全投稿を見られることになる。

Postクラスや継承元のModelクラスはall()メソッドを持たないが、store()アクションで見たのと同じようにModelクラスのマジックメソッドから呼び出していると思われる。

投稿記事の配列はresource/posts/index.blade.phpに'posts'として渡され、これがindexビューで$postsとして利用される。

表示ビュー

投稿表示はindex.blade.phpに以下の要領で記述。

  @forelse ($posts as $post)
    <p>{{ $post->comment }} : {{ $post->created_at }}</p>
  @empty
    <p>投稿はありません。</p>
  @endforelse

@forelse ($posts as $post)

<p>{{ $post->comment }} : {{ $post->created_at }}</p>

@empty

<p>投稿はありません。</p>

@endforelse

ここでは@forelseディレクティブで$postsに格納された投稿記事群を一つずつ取り出して、commentとcreated_at(datetime型)を表示させている。

$postsはindexアクションで読み込まれた投稿記事を格納した配列。

@forelseを使っているので、$postsが空の場合、つまり投稿が一つもされていない場合は、それに対応したメッセージが表示される。

Laravel – モデルデータの操作

2021-10-10 / tau / コメントする

概要

ここではモデルを使った基本の流れを整理する。

フォームで入力したデータをデータベースに登録
データベースのデータを表示
登録されたデータを編集・更新
登録されたデータの削除

例として、短いコメントを書き込む掲示板を想定する。

設定

ユーザー認証機能を実装。

データとしてユーザーが入力した投稿記事を扱う。

モデルは投稿記事を表すPost
コントローラーはPostController
postsに対するリソースルーティングを使う

準備

モデル

artisanでモデルを作成。

$ php artisan make:model Post

1	$ php artisan make:model Post

マイグレーションファイルを編集し、マイグレート。

投稿本文はcommentとし、200文字の文字列
自動生成されるtimestampsをdatetime型のcreated_atとupdated_atに変更(2038問題対応)
user_idはusersのidを外部キーとして持つ
→外部キー参照

public function up()
{
    Schema::create('posts', function (Blueprint $table) {
        $table->bigIncrements('id');

        // ユーザーIDの外部キー
        $table->unsignedBigInteger('user_id');

        // コメント本文
        $table->string('comment', 200);

        // $table->timestamps();
        $table->datetime('created_at');
        $table->datetime('updated_at');

        // 外部キー制約設定
        $table->foreign('user_id')->references('id')->on('users')
        ->onUpdate('cascade')
        ->onDelete('cascade');
}

public function up()

{

Schema::create('posts', function (Blueprint $table) {

$table->bigIncrements('id');

// ユーザーIDの外部キー

$table->unsignedBigInteger('user_id');

// コメント本文

$table->string('comment', 200);

// $table->timestamps();

$table->datetime('created_at');

$table->datetime('updated_at');

// 外部キー制約設定

$table->foreign('user_id')->references('id')->on('users')

->onUpdate('cascade')

->onDelete('cascade');

}

コントローラー

artisanでコントローラーを作成。

$ php artisan make:controller PostController

1	$ php artisan make:controller PostController

ルーティング

postsに対してPostControllerを割り当てるリソースルーティングを記述。

Route::resource('posts', 'PostController');

1	Route::resource('posts', 'PostController');

Postモデルに関するリソースルーティングは以下の通り。

$ php artisan route:list
+--------+-----------+------------------------+------------------+------------------------------------------------------------------------+--------------+
| Domain | Method    | URI                    | Name             | Action                                                                 | Middleware   |
+--------+-----------+------------------------+------------------+------------------------------------------------------------------------+--------------+
........
|        | POST      | posts                  | posts.store      | App\Http\Controllers\PostController@store                              | web,auth     |
|        | GET|HEAD  | posts                  | posts.index      | App\Http\Controllers\PostController@index                              | web,auth     |
|        | GET|HEAD  | posts/create           | posts.create     | App\Http\Controllers\PostController@create                             | web,auth     |
|        | GET|HEAD  | posts/{post}           | posts.show       | App\Http\Controllers\PostController@show                               | web,auth     |
|        | DELETE    | posts/{post}           | posts.destroy    | App\Http\Controllers\PostController@destroy                            | web,auth     |
|        | PUT|PATCH | posts/{post}           | posts.update     | App\Http\Controllers\PostController@update                             | web,auth     |
|        | GET|HEAD  | posts/{post}/edit      | posts.edit       | App\Http\Controllers\PostController@edit                               | web,auth     |
........

$ php artisan route:list

+--------+-----------+------------------------+------------------+------------------------------------------------------------------------+--------------+

+--------+-----------+------------------------+------------------+------------------------------------------------------------------------+--------------+

........

| | GET|HEAD | posts/{post} | posts.show | App\Http\Controllers\PostController@show | web,auth |

| | DELETE | posts/{post} | posts.destroy | App\Http\Controllers\PostController@destroy | web,auth |

| | PUT|PATCH | posts/{post} | posts.update | App\Http\Controllers\PostController@update | web,auth |

| | GET|HEAD | posts/{post}/edit | posts.edit | App\Http\Controllers\PostController@edit | web,auth |

........

アクセス制限

ログインユーザーのみページを見ることができるようアクセス制限をかける場合は、PostControllerのコンストラクターでミドルウェアを指定する。

class PostController extends Controller
{
    public function __construct()
    {
      $this->middleware('auth');
    }
    ....
}

class PostController extends Controller

{

public function __construct()

{

$this->middleware('auth');

}

....

}

データの操作

Laravel – データが属しているユーザーを取り出す

2021-10-09 / tau / コメントする

概要

投稿記事を投稿したユーザーや商品カートの保有ユーザーなど、データが所属しているユーザーを取り出す場合。1対多のリレーションの多に属するデータから1のデータを取得する。

データモデルにリレーションを設定することで、そのデータが属するユーザーを属性として取り出すことができる。

手順

データモデルにuser()メソッドを定義し、そのデータがUserモデルのデータに属していることを記述する。メソッド名はUserの単数形となっていることに注意。

class モデル extends Model
{
    ....
    // リレーション設定
    public function user() {
      return $this->belongsTo('App\User');
    }
}

class モデル extends Model

{

....

// リレーション設定

public function user() {

return $this->belongsTo('App\User');

}

これによってデータモデルにuser属性が追加され、それを介してUserの各属性を取得することができる。

モデルデータ->user->name

例

例えばユーザー認証は設定済みとして、ユーザーの投稿記事モデルPostsを定義済みとする。Postモデルは記事の投稿ユーザーのIDをuser_idとして持ち、外部キー制約を設定している。

mysql> DESCRIBE posts;
+------------+-----------------+------+-----+---------+----------------+
| Field      | Type            | Null | Key | Default | Extra          |
+------------+-----------------+------+-----+---------+----------------+
| id         | bigint unsigned | NO   | PRI | NULL    | auto_increment |
| user_id    | bigint unsigned | NO   | MUL | NULL    |                |
| comment    | varchar(200)    | NO   |     | NULL    |                |
| image_name | varchar(100)    | NO   |     | NULL    |                |
| created_at | datetime        | NO   |     | NULL    |                |
| updated_at | datetime        | NO   |     | NULL    |                |
+------------+-----------------+------+-----+---------+----------------+
6 rows in set (0.00 sec)

mysql> DESCRIBE posts;

+------------+-----------------+------+-----+---------+----------------+

+------------+-----------------+------+-----+---------+----------------+

| id | bigint unsigned | NO | PRI | NULL | auto_increment |

+------------+-----------------+------+-----+---------+----------------+

6 rows in set (0.00 sec)

まずPostモデルにuser()メソッドを定義し、belongsTo(App\User)を戻り値とする。

belongsTo()はPostモデルがUserモデルに属することから、Postのインスタンスが属するUserのインスタンスを返す
このリレーション設定によって、Postモデルにuserプロパティーが加えられ、Postインスタンスが属するUserのインスタンスを取得できる

class Post extends Model
{
    ....
    // リレーション設定
    public function user() {
      return $this->belongsTo('App\User');
    }
}

class Post extends Model

{

....

// リレーション設定

public function user() {

return $this->belongsTo('App\User');

}

これでPostインスタンスのuserプロパティーに、その記事を投稿したユーザーへの参照が格納される。

たとえば投稿記事が$postに格納されているとして、ビュー側でユーザーを取得して表示する場合、以下のようなディレクティブになる。

<p>{{ $post->user->name }}さんの記事 : {{ $post->comment }}</p>

1	<p>{{ $post->user->name }}さんの記事 : {{ $post->comment }}</p>

Laravel – ログインユーザーのデータのみ取り出す

2021-10-09 / tau / コメントする

概要

ユーザーが投稿した記事や購入予定のカート・商品など、ログインユーザーに関するもののみを利用したい場合。1対多のリレーションの1から多のデータ群を取得する。

以下のいずれかの方法がある。

モデルのwhere()->get()で抽出する
Userモデルにリレーションを定義し、Userのプロパティーとして取得する

where()メソッドを使う方法

手順

全ての記事を取得するならコントローラーのアクションでPost::all()として取り出すが、この場合はwhere()メソッドで全データのうちuser_idがログインユーザーのidと同じデータだけを抽出する。

SQLではWHERE user_id = ログインユーザーidとなるが、Laravelでは以下のように書く。

モデル::where('モデルのユーザーid', \Auth::user()->id)->get()

例

mysql> DESCRIBE posts;
+------------+-----------------+------+-----+---------+----------------+
| Field      | Type            | Null | Key | Default | Extra          |
+------------+-----------------+------+-----+---------+----------------+
| id         | bigint unsigned | NO   | PRI | NULL    | auto_increment |
| user_id    | bigint unsigned | NO   | MUL | NULL    |                |
| comment    | varchar(200)    | NO   |     | NULL    |                |
| image_name | varchar(100)    | NO   |     | NULL    |                |
| created_at | datetime        | NO   |     | NULL    |                |
| updated_at | datetime        | NO   |     | NULL    |                |
+------------+-----------------+------+-----+---------+----------------+
6 rows in set (0.00 sec)

mysql> DESCRIBE posts;

+------------+-----------------+------+-----+---------+----------------+

+------------+-----------------+------+-----+---------+----------------+

| id | bigint unsigned | NO | PRI | NULL | auto_increment |

+------------+-----------------+------+-----+---------+----------------+

6 rows in set (0.00 sec)

以下はログインユーザーの全記事をPostControllerのindexアクションで取得し、indexビューで表示させる例。ビュー側で受け取った$postsにログインユーザーが投稿した記事だけが配列で格納される。

class PostController extends Controller
{
    ....
    public function index()
    {
        $posts = Post::where('user_id', \Auth::user()->id)->get();

        return view('posts.index', [
          'title' => '投稿一覧',
          'posts' => $posts,
        ]);
    }
}

class PostController extends Controller

{

....

public function index()

{

$posts = Post::where('user_id', \Auth::user()->id)->get();

return view('posts.index', [

'title' => '投稿一覧',

'posts' => $posts,

]);

}

モデルのリレーションを定義する方法

手順

Userモデルにモデル名の複数形(テーブル名に相当)でメソッドを定義し、リレーションを記述する。

class User extends Authenticatable
{
    ....
    // リレーション設定
    public function メソッド名() {
      return $this->hasMany('App\モデル名');
    }
}

class User extends Authenticatable

{

....

// リレーション設定

public function メソッド名() {

return $this->hasMany('App\モデル名');

}

これによってUserモデルの属性にメソッド名と同名のプロパティーが追加され、そのユーザーのidを外部キーに持つモデルのデータのみを取り出すことができる。

そしてコントローラーのアクションで、ログインユーザーのプロパティーでログインユーザーのidを持つデータのみを取得できる。

class コントローラー extends Controller
{
    ....
    public function アクション()
    {
        $login_users_data = \Auth::user()->メソッド名;
        ....
    }
}

class コントローラー extends Controller

{

....

public function アクション()

{

$login_users_data = \Auth::user()->メソッド名;

....

}

例

以下は先と同じPostモデルを扱う例。

まずUserモデルにPostの複数形(テーブル名)でposts()メソッドを定義し、hasMany(App\Post)を戻り値とする。

hasMany()は元のモデル(User)が複数の引数モデルを持つことから、Userのインスタンスに属する複数のデータの配列を返す
このリレーション設定によって、Userモデルにpostsプロパティーが加えられ、Userインスタンスに属するPostの配列を取得できる

class User extends Authenticatable
{
    ....
    // リレーション設定
    public function posts() {
      return $this->hasMany('App\Post');
    }
}

class User extends Authenticatable

{

....

// リレーション設定

public function posts() {

return $this->hasMany('App\Post');

}

これでユーザーのインスタンスのpostsプロパティーに、そのユーザーが投稿した記事だけが格納される。

コントローラーではログインユーザー(\Auth::user())のpostsプロパティーを参照すればよいので、以下のようになる。

class PostController extends Controller
{
    ....
    public function index()
    {
        $posts = \Auth::user()->posts;

        return view('posts.index', [
          'title' => '投稿一覧',
          'posts' => $posts,
        ]);
    }
}

class PostController extends Controller

{

....

public function index()

{

$posts = \Auth::user()->posts;

return view('posts.index', [

'title' => '投稿一覧',

'posts' => $posts,

]);

}