2018-06-18

【Laravel】Eager-Loadingでlimitを使ってはいけない

概要

いけないというか、Eager-Loadingでlimitを利用する際は挙動をちゃんと理解していないと思わぬ動作をする。

本題

以下のようなテーブルがあった際に、Bookに紐づくChapterをEager-Loadingを利用して、それぞれの本の最後の章を取得したい場合を考える。

Books
--------------
| id |  name |
|----|-------|
|  1 | book1 |
|  2 | book2 |
|  3 | book3 |
-------------

Chapters
------------------------------
| id | book_id | chapter_num |
|----|---------|-------------|
|  1 |       1 |           1 |
|  2 |       1 |           2 |
|  3 |       2 |           1 |
|  4 |       2 |           2 |
|  5 |       3 |           1 |
------------------------------

そのためにまず、Book-Chapterのテーブル結合を行う。

public function lastChapter()
{
  return $this->hasMany(Chapter::class)
  ->orderBy('chapter_num', 'desc');
}

$books = Book::with(['lastChapter',])->get()

ここで、私は最後の章だけを取得したいが、現在のlastChapterではchapter_num順に並び替えられているだけなので、 limit(1)を付与すれば、各Bookの最終章を取れるのではないか、と考えたのでlimit(1)を付与した。

public function lastChapter()
{
  return $this->hasMany(Chapter::class)
  ->orderBy('chapter_num', 'desc')
  ->limit(1);
}

しかしながら、limit(1)を付与すると3つのBook中2つのBookのlastChapterが空っぽだった。ここで、Eager-Loadingの挙動について調べてみると、

Eager-Loadingによりlimit(1)を付与する前のlastChapterは以下のように変換される。

SELECT 
* 
FROM `chapters` 
WHERE `chapters`.`book_id` IN ('1', '2', '3')
 ORDER BY `id` DESC

なんと、内部的にはjoinしているのではなく、Chaptersのテーブルから含まれるBookのidをIN句で取得していた。なるほど、ということはBooksとChaptersをjoinするのではなく、BooksとChaptersを別々に取得して各Collectionオブジェクトを結合しているらしい。

そのため、limit(1)を付与すると以下のクエリが発行されるが、Chaptersのデータが1行しか取れずに、 Booksの結果CollectionとChaptersの結果Collectionで結合できるのが1行のデータ分しか結合できないため、 3つ中2つのBookのlastChapterが空っぽになるというわけだ。

SELECT 
* 
FROM `chapters` 
WHERE `chapters`.`book_id` IN ('1', '2', '3')
 ORDER BY `id` DESC limit 1

そのため、最終章を取得するためにはEager-Loadingは利用せずにクエリビルダーを使って最適なクエリを自前で記述するか、 Eager-Loadingを利用して最終章以外のデータも取得されてしまうが、それを受け入れて以下のように処理するのが良いだろう。

foreach($books as $book){
  $book->lastChapter->first()
}

2018-06-17

【Laravel】ファイルキャッシュが動くかテスト

概要

ファイルキャッシュを使って、1分経過したらキャッシュから消えるようにした。

方法

実際に、Laravelのドキュメントの通りに実装すると

/storage/framework/cacheの場所にキャッシュができていた。

$value = \Cache::store('file')->remember('key', 1, function() {
    return DB::table('test')->get();
});

1分後にキャッシュが消えていることを確認すべく/storage/framework/cacheに作成されたキャッシュデータを確認したが、いくら待てども消えなかった。なぜ消えないかはさておき、別の方法としてhasメソッドを使ってキャッシュの存在を確認してみた。

if (\Cache::store('file')->has("key")) {
  // 存在する場合
}else{
  // 存在しない場合
}

これを実行すると、1分後にキャッシュが存在しない場合のほうに処理が入ったので、とりあえずキャッシュは消えていそうである。

追記

不要なキャッシュを削除するためにはどうやらLaravelはキャッシュクリアコマンド(artisan)を利用する必要がありそう。

qiita.com

2018-06-17

Laravelのアーキテクチャ

概要

自分的なLaravelの運用しやすいアーキテクチャ案ができたのでメモ。細かい部分はプロジェクトによって異なると思うので、大枠的なアーキテクチャを述べる。

自分なりの考え

LaravelではMVCとしての開発の準備が充実しているため、MVCをベースとしたアーキテクチャーについて考える。

MVCはオブジェクト指向プログラミングではよく聞くWebアプリケーションの作り方であるが、Modelを効果的にデザインすることで見通しの立ちやすいコードを書くことができる。 Webアプリケーションは開発してそのまま、ということはなく機能拡張を行ったりパフォーマンスチューニングを行ったり、メンテナンスされていくものであるため、機能拡張や変更に対応していくことのできるアーキテクチャにすることが理想的である。そのため、見通しの良いコードを書くことは機能拡張の際にも柔軟に対応することができるようになり理想に近づくことができる。

ところで、LaravelではMVCの開発の準備がされているものの、Laravel側としてはどういうMVCを構築してほしいのかを考えてみる。LaravelではControllerとViewを格納するためのフォルダは用意されている。しかしながら、Model用のフォルダは用意されていない。理由はMVCのMがどういうことをするか、どういう構成にするかは人によって異なるからである。人によっては論理操作やDB操作を単一のModelに全て押し込める人もいるだろうし、そうでない人もいるが私なりのModelデザインをこれからしていく。一般的に、Modelで行ってほしいことは以下である。

ビジネスロジック
DB操作

なるべくControllerには無用に命令的なコードを書かずに、論理で追っていくことのできるスタイルが理想であると私は考えている。以降で「論理」という言葉が多用されるが、その意味は「処理を意味的なものにする」くらいに思っておいてほしいが、多分説明になっていないので下記のコードで説明する。足し算をする、というコードがあったとする。その際には、以下のように書く。

$a = 1;
$b = 2;
$result = a + b;

しかしながら、addというメソッドを用意することで以下のように書き換えることができる。

$a = 1;
$b = 2;
$result = add(a, b); // addメソッドはどこかで宣言されている

例のスケールが小さすぎるので何が嬉しいかはわかりにくいが、後者はaddメソッドによりaとbを足すんだな、と一目見ただけでわかる。このaddメソッドのように命令的な処理を関数化した、意味単位で処理のまとまりを「論理」と呼ぶことにする。

話をModelに戻す。Cotrollerではなるべく論理を利用してコードを書くために、命令的な部分(ビジネスロジックやDB操作)はModelとして水面下に隠されるべきである。

そのために、まずビジネスロジックはどのように水面下に隠すべきであるか。ビジネスロジックとはどういった存在であるかを考えると、単なる論理であるべきで、それ自身がオブジェクトになったりするものではない。そうしたことを踏まえるとphpにはtraitが使えるのでこれを使用する。traitのような論理を格納する場所はいまのところないので「Traits」や「Services」のような名前のディレクトリを作って、そこへ入れてあげれば良い。これにより、オブジェクト指向でありながら関数型プログラミングのような論理によるコードを書くことができ、コードの見通しが立ちやすくなる。

.

├── Cotrollers
│   └── UserCotroller.php
│
├── Services(Traitsでも良いと思う)
│   └── UserService.php(UserTraits.phpでも良いと思う)

これでビジネスロジックはControllerから剥がすことができたので、次はDB処理の仕方を考える。 Laravelを利用しているのであればぜひEloquentを利用するべきである。 Eloquentでは以下のような記法でDB処理を行う(joinの例)。我々がDBに対してjoin句を書く部分はhasOneメソッドにより論理的な操作ができるようになっている。

// 連携情報の宣言(論理の宣言)
public function foo()
{
    return $this->hasOne('連携先テーブル名');
}

// 連携情報の宣言(論理の宣言)
public function foo2()
{
    return $this-where('id' > 0);
}

// 上記の宣言を利用するためには次のようにする
$result = $this->first();
$result->foo();
$result->load(['foo2'])

// もしくは
$result = $this->with(['foo2'])->first();

これがEloquentの強みであるが、上記の一連のDB操作は大きく分けて「論理の宣言」と「利用」部分で分割することができる。そのため、DB操作をさらに「論理」と「利用」に分けることで、DB操作の部分がごちゃごちゃしないスマートなアーキテクチャにすることができる。

これを実現するのにDBアクセスの処理をビジネスロジックから切り離す手法であるRepositroyパターンを使用する。調べてみるとRepositoryパターンをLaravelで導入するQiita記事(これ)があるためこれを参考にして話を進める。

上記の記事では以下のような構成にしているので同じ構成にする。

.

├── Models
│   ├── User.php
│   
├── Repositories
    └── User
        ├── UserRepository.php
        └── UserRepositoryInterface.php

さて、ModelsとRepositoriesの2つのディレクトリを作成することになるが、Modelsは論理を書く場所、RepositoriesはModelsで宣言されたレゴブロックを組み立てる場所として使う。私の中でのルールはControllerからDB処理を呼び出すのはRepositoriesであり、原則Modelを直接呼び出さない。中には、Repositoriesなんか必要なくてControllerに書けばよい、という人もいると思う。確かにディレクトリが増えるし、概念も増えてしまっている。しかし、残念ながら全てのDB操作がEloquentで済まない場合があったり、DB操作をチューニングして高速にしたい場合、どのようにするか。もしRepositoriesがない場合はControllerかModelsにDB処理を書くことになる。そうすると、ControllerもしくはModelsの役割がごちゃごちゃしてしまったり、Controllerが太ってしまったり残念なことになってしまう。

結果

MVCのMをService(トレイト)とRepository(レポジトリ)とModel(Eloquentの論理宣言)の3つに分かれたが、これにより各機能が意味的に分割され、更には処理を論理的な操作で可能にすることにより、見通しが立ちやすく、保守しやすいものになった(と思っている)。

(おまけ)Laravelのここが良い

しっかりとしたアーキテクチャを構成するために使いたいLaravelの機能。

Eloquent ORM

Eloquentを利用することで見通しの良いDB操作を行うことができる。テーブル連携では以下のように記述することができる。引数を省略すると、自モデルの'連携先テーブル名'_idと連携先テーブルのidが紐づけられる。第二引数と第三引数を指定することで紐づけるキーを変更することができる。例では1対1のテーブル連携であるが、メソッドを変えることで1対多や多対多の連携もできる。

Eloquentを利用することで、処理を論理的に記述することができソースコードの見通しが良くなる。

$this.hasOne('連携先テーブル名');

また、ミューテータも非常に便利である。以下のようにgetFooAttributeというメソッドを宣言すると、first_nameへアクセスする際データはucfirstメソッドを通した形で取得することができる。つまりDBとModelの間に立つmiddlewareのような操作をさせることができる。今回の例ではあまり実感はないが、nullの値は空白やデフォルト文字にすることができたり金額は税率によって変わってしまうため、middlewareで税率を積算させることができるなど、様々な箇所で便利に使えるであろう。

public function getFirstNameAttribute($value)
{
    return ucfirst($value);
}

これの逆パターンとして(getではなくset)も行うことができて、これをミューテータを呼ぶ。例えば全部英子文字の入力を期待するが、大文字が入力された場合もミューテータを通すことにより小文字でDB登録することができる。

public function setFirstNameAttribute($value)
{
    $this->attributes['first_name'] = strtolower($value);
}

更に、Eloquentを使用して終端メソッド(getやall)を利用した際はCollectionオブジェクトを取得することができる。 Collectionオブジェクトでは関数型プログラミング(のような手法)でmapやfilter等によりDBの取得結果に対して操作をすることができる。 Collectionオブジェクトを論理により操作することもまたコードの見通しを良くすることができる非常に強力な機能である。

2018-06-17

ブラウザバック時にFORM送信された値が保持されない

html

概要

取り扱っているシステムでブラウザバック時にFORM送信された値が保持されない箇所があったので原因を調査した。

状況

選択肢1と選択肢2が存在し以下の流れでブラウザバックをする。

選択肢1の値はサーバサイドで作られる
選択肢1の選択に追従して選択肢2の値をXHR(Ajax等)で取得して変更する(初期表示の際は選択肢1の値を元にXHRでデータ取得をする)
選択肢2を選択する
ブラウザバック

そうすると選択肢1ではFORMで送信した値が保持されるが、選択肢2では値が保持されない。気づく人はこの時点でオチがわかるかもしれないが原因は以下。

原因

ブラウザバック時に選択肢1と選択肢2で選択した値が、前画面の選択肢1と選択肢2にセットされる。選択肢1のデータはサーバサイドで作られるため、view上には選択肢1の収まるデータが存在するためブラウザバックしても値は保持される。この際、選択肢2のデータリストは選択肢1の値をもとにXHRで取得されるため、選択肢2の初期のデータリストは空っぽである。初期状態の選択肢2のデータリストが空のため、ブラウザバック時に選択肢2が収まる場所がないため、選択肢2の値が消滅してしまう。

対策

選択肢2に入りうる値をサーバサイド側でviewに詰め込む
選択肢2の変更に追従するhiddenタグを用意する。選択肢2の値が変更されたらhiddenの値を利用して初期状態をセットしてあげる

2018-06-15

【Python】ImproperlyConfigured: MySQLdb must be installed.がでた

error python

概要

peeweeにおいてconnectやcreate_tableを行う際に、以下のエラーが発生したためメモ。

ImproperlyConfigured: MySQLdb must be installed.

解決法

PythonからMySQLを操作するモジュールをpip経由でinstallすれば解決。

pip3 install PyMySQL

// もしくは

sudo pip3 install PyMySQL

// もしくは

pip install PyMySQL

// もしくは

sudo pip install PyMySQL

// もしくは

2018-06-15

MySQLを動かすことができない場合の対処方法

mysql

概要

以下のエラーが発生したためメモ。

ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2)

詳細

mysql起動

「mysql」コマンドを実行しても上記のエラーが発生して先に進まない

service mysql start

エラーログをみる

エラーログは以下の場所へ出力されている。

/var/log/mysql/error.log

エラーログを見てみるとソケットファイルを作成できなかったとわかる

Could not create unix socket lock file /var/run/mysqld/mysqld.sock.lock.

mysqlユーザに権限を与える

ソケットファイルが作れるようにmysqlユーザに権限を与える

sudo chown mysql:mysql /var/run/mysqld

以下のコマンドで動かせばOK

service mysql start

2018-06-10

【Python】oduleNotFoundError: No module named 'builtin'

error python

概要

以下のエラーが発生したためメモ。Python3では__buildin__が利用できない。

ModuleNotFoundError: No module named '__builtin__'

解決策

__buildin__の代わりにbuiltinsを利用する。

# import __builtin__ ※これは使えない
import builtins

# __builtin__.__import__(引数) ※これは使えない
builtins.__import__(引数)

mk-toolブログ

エンジニアと家のことをごちゃごちゃと書いてます

【Laravel】Eager-Loadingでlimitを使ってはいけない

概要

本題

【Laravel】ファイルキャッシュが動くかテスト

概要

方法

追記

Laravelのアーキテクチャ

概要

自分なりの考え

結果

(おまけ)Laravelのここが良い

Eloquent ORM

ブラウザバック時にFORM送信された値が保持されない

概要

状況

原因

対策

【Python】ImproperlyConfigured: MySQLdb must be installed.がでた

概要

解決法

MySQLを動かすことができない場合の対処方法

概要

詳細

mysql起動

エラーログをみる

mysqlユーザに権限を与える

以下のコマンドで動かせばOK

【Python】oduleNotFoundError: No module named 'builtin'

概要

解決策