タグ: Laravel

ここ数年Laravelを使っているのですがとても味わい深いフレームワークです。普通に使う分には意識せずコードはかけますしこういった機能はないのか？と思って探してみると大体見つかりどんどん書き方が変わってきます。

今回は開発を続けていく上で同じようなコードが分散していかないようにする為の方法の1つを書き留めておきます。リレーションがたくさんできていくと同じコードを書いてしまうことがあります。最初はコピペで良くても後から振る舞いが少し変えるためには同じようなコードを全部修正する必要がでてきますし確認も大変です。

下記はブログとブログの記事の作成者の名前を取得する例のコードです。

class Blog extends Model
{
    use UserTrait;
}

class BlogEntry extends Model
{
    use UserTrait;
}

trait UserTrait
{
    public function user()
    {
        return $this->belongsTo(User::class);
    }

    public function getUserNameAttribute()
    {
        if ($this->user) {
            // Userが存在するならユーザー名を返却
            return $this->user->name;
        }
        // Userが存在しない場合
        return '';
    }
}

こちら作成者が存在すれば名前をなければブランクを返すという簡単な流れです。Blog,BlogEntryともにuser_idで連結されており他にも同じようにuser_idによる連結がされる場合traitをuseするだけでいいので修正が楽です。こちらのいい所は途中でユーザーがいない場合ブランクではなく「退会されました」の文字列に連携するなどが容易なのに加えあとでユーザーに属性が追加されても呼び出す元は変更せずUserのTraitさえ変更すれば容易に追加できる点です。他にもAttribute以外にももちろんscopeやbootなど色々使えるでしょうしおすすめです。

開発中であればエラーはそのまま表示されるので解決は比較的容易ですが、運用中に発生した場合はエラーログから調査するので少し時間がかかります。

エラーログにはデフォルトで発生時ログインしているuserIdが一緒に出力されエラーが発生したファイル名や行番号も出力されるので基本的にはそちらからエラーの調査は行えますが、特定のレコード時だけ発生したなどになるとそれだけでは時間がかかる時があります。

なので出力されるログの内容を拡張できないかフレームワークのソースを調べたところ

Illuminate/Foundation/Exceptions/Handler.php
にcontextと目的の関数があり

contextの関数をオーバーライドすればいい様子

以下実装例

app/Exceptions/Handler.php
/**
 * ログに記載する追加情報
 */
protected function context()
{
    $context = parent::context();
    try {
        return array_merge($context, [
          // 一緒に記録したい情報
          'uri' => env('REQUEST_URI'),
        ]);
    } catch (Throwable $e) {
        return $context;
    }
}

以上！

最初は5.1から5.5に一気にあげようかと思いましたが、順次あげていったほうが最終的には早く終わりそうだったので、Laravelのアップグレード手順と他の方の記事を参考にしながらアップグレードを行いました。
せっかくなのと覚書を兼用してつまづいた部分をいくつか紹介します。

5.1 ＞ 5.2

composer updateでエラー

Illuminate\Foundation\ComposerScripts::postUpdate
php artisan optimize
PHP Fatal error: Uncaught ReflectionException: Class log does not exist in vendor/laravel/framework/src/Illuminate/Container/Container.php:734
Stack trace:

原因は.envに定義している配列の書き方がまずかった模様

ALLOW_IPS=[“192.168.111.111”, “192.168.111.123”]

こちらスペースを削除したら問題なく動作しました。

5.2 ＞ 5.3

bladeを拡張していた部分でエラー

(‘aaa’, $bbb->ccc)

これまでblade拡張のdirectiveにて上記のようにパラメータが来ていたが、5.3になってからは下記のように外側の括弧がなくなりマッチせずエラーに

‘aaa’, $bbb->ccc

こちらは括弧がない文字列でマッチ条件を変更

5.3 ＞ 5.4

・使用していたSlackのライブラリが使えなくなった ＞ 別のライブラリに変更
・関数名がリネームされていた ＞ forceSchemaをforceSchemeに書き換え

5.4 ＞ 5.5

・Filesystemのfilesメソッドの挙動がSplFileInfoを返すようになったので、実行前にis_dirで確認を追加しました。
・Requestのhas,onlyメソッドの挙動が少し変わっていたので適宜書き換え

動作確認やアップグレード中に不具合修正が入ったり等で少し時間がかかりましたが、基本的にはアップグレード手順書通り行えばそこまで問題はなさそうです。

技術系のメモ書き程度のことですが、メール送信処理や時間のかかる処理等をLaravelのQueueを初めて使って困ったところを書いておきます。

結論を先に書くと
1. listenよりworkを使う
2. ドライバーにdatabaseを使う場合は複数立ち上げない

1. listenよりworkを使う

処理の優先順や別々の機能等があり何個かQueue処理を作ってそれぞれlistenで立ち上げていたのですが、複数立ち上げていくとCPU使用率がどんどん上昇してしまい最終的にはちょっと実用に耐えられないぐらい上がってしまいました。

もともとlistenで立ち上げるとCPUを食うことは知っていましたが、listen1つでここまでCPUを使うとは・・・

こちらはlistenからworkに変更することで問題は解決しました。
全然CPUにかかる負担が違う。

2. ドライバーにdatabaseを使う場合は複数立ち上げない

基本的にはSQS等を使えば問題ないとは思いますが、当面は処理量も少なくまたローカル開発環境で手軽に使える為、ドライバーにdatabaseを使用していました。

特に処理も滞りなさそうに動いていたのですが、複数のqueueを立ち上げているとログに不穏なものが・・・

Deadlock found when trying to get lock; try restarting transaction

調べてみると、どうやらドライバーにdatabaseを使用して複数立ち上げると発生するっぽい。
とりあえず基本的に量が少ないうちだけdatabaseを使用して、処理量が多くなったらSQS等にドライバーを切り替える予定なので、当面は同じQueueについては1つのみ立ち上げる形で運用しています。

以上、LaravelでQueueを使って困ったことでした！

あとがき
次のLTS出たのでそろそろバージョンを上げたい。
・・・でもそんな時間がまだ取れないorz
いつになるかわかりませんが、5.1から5.5に上げた時に困ったことを記事に書く予定です。