isDirty() vs wasChanged()(更新)
3年前に書いた投稿の更新です(その投稿自体その4年前の投稿の更新です)。factoryからEloquentのインスタンスの作成も変わり、また新たな発見がありました。
3年前に書いた投稿の更新です(その投稿自体その4年前の投稿の更新です)。factoryからEloquentのインスタンスの作成も変わり、また新たな発見がありました。
さらに引き続いて、最新のバージョンのLaravel 8.xの話です。今回はfactoryの話です。
以前投稿したbulk insertで大量のデータをDBに登録するの記事では10万レコードの挿入をbulk insertで行い、通常のinsertと比べてどれだけ速くなるのか検証しました。結果は一目瞭然で、大量のレコードをDBに登録する際には強力な武器になる事が分かりました。 しかし、前回のコードを実際の運用で使うには1つ問題があります。それはbulk insertの途中でエラーが発生した場合、DBに中途半端にレコードが残ってしまうという問題です。今回はこの問題を解決するために、前回のコードをtransactionに入れ、エラーが発生した際にロールバックされるように改修します。そして、transaction処理にする事でパフォーマンスにどのような影響があるか検証してみます。
毎日走らせているcronのジョブの1つが、なかなか時間が掛かるのでどうにか改善できないかと悩んでいました。DBへデータを挿入する箇所で時間が掛かっており、コードを確認するとforループで1レコードずつinsert処理を行っていました。bulk insertするように改修したところ、劇的に処理時間が短くなりました。今回はそんな妙薬、bulk insertについてです。
既存のDBのそれぞれのテーブルにおいて、migrationファイルやfactoryファイルが揃ったところで、phpunitのテストを作成して実行してみましょう。
既存のDBからmigrationファイルを自動作成によって、テストのために空のDBテーブルの作成が可能となりました。今度は、そこへテストデータを作成するためにfactoryが必要となります。これも自動作成しましょう。
tinker好きの私としては、嬉しいニュースです。今までコンソールからでしか使用できなかったtinkerがブラウザでアクセスできるようになりました。と言っても、Laravelのパッケージの一部ではなく、Laravelのtinkerにフロントエンドを追加したphpのパッケージ、Web Tinkerのことです。
tinkerを使用して開発中の関数をいろいろ試験します。Eloquent関連の関数で複数のDBテーブルに渡り値を更新する関数ゆえに、tinkerがとても役に立つのです。しかし、試験中に不思議なことが起こりました。ちょっと格闘して、なるほどそこではこうすればいいのだな、という話を共有です。
以前からお客さんのプロジェクトの管理画面のダッシュボードに日別や月別の売り上げ合計や会員の獲得数などをグラフで表示したいと思っていました。もちろん、グラフを作成するjavascriptのライブラリはいくつかありますが、習得にも開発にも時間がたくさんかかりそうです。そこで私の目に留まったのが、Googleデータポータル。データソースを指定してビジュアルなツールでちょいちょいとグラフ化できそうです。今回は、それを使用してMySQLのデータベースから月別に登録した会員数の棒グラフの作成の仕方を説明します。
このブログの一番最初に書いた記事において、isDirty()に関して書きました。もう4年くらい前のことです。最近必要になって使用したところ、新たな発見がありました。