GORMのVersionを上げたお話 Go Conference 2021 Autumn Fumiya Suzuki @sntree_suzunoki

GORM ● GoのORMで一番スター数が多く、 一番機能が多い ● 直感的にクエリを書くことができて、 初心者でもわかりやすい ● 内部ではreflectを用いて対象の structを認識するので、コード生成を 必要としない ● 2020/08にv2がリリースされた

V2 Release Note ● V2はスクラッチで書き直された ● 欲しかった機能がたくさん追加されて いる！ ● パフォーマンスも向上したみた い！！！

よーしお兄さんパフォーマンスあげちゃうぞ

こんなはずじゃなかった...

苦労したポイント The Gopher character is based on the Go mascot designed by Renée French .

とにかく修正量が多い ● 微妙にクエリが変わるため、GORMを使用している全ての箇所で発行されるクエリ を確認する必要がある ● 引数の型が変更されたり、エラーの判別方法が変更されているのでこれも修正して 回る必要がある ● go-sqlmock等で用意しているモックはほぼ全てに修正が必要になる ● タグのタイポなどでサラッとミスしてエラーが出ないので、単体テストがない場合は 書いていかないと動作を保証しづらい

無限のクエリでmapが膨れ上がる ● Prepareされた結果やコネクションの情報はクエリをkeyにしてGORM内部のmap に保存される ● 二回目以降はそのマップからの情報を利用して、二度目のPrepareをしない Prepare map[string]gorm.Stmt Excute map[string]gorm.Stmt Excute 解析結果

無限のクエリでmapが膨れ上がる ● このmapは上限もなくevictionされることがないため、fmt.Sprintfなどで動的にクエ リを構築などをしているとマップが膨れ上がる ● また、DBのキャッシュできるStatementの最大数に達してしまい、新たにPrepareで きなくなる ● 動的に構築している部分を書き直していき、複雑すぎるところはそこだけ PrepareStatementModeを利用しないようにした Prepare map[string]gorm.Stmt Excute 解析結果 解析結果 解析結果 解析結果 ・ ・ ・ ・ ・ ・

既存の実装に悩まされる ● 自由、便利、なんとなく動く ○ 同じクエリに対して何通りも書き方があるので、人によって書き方が全然違う ○ 同じモデルを色々なところで使いまわしているため修正の影響範囲が大きすぎる ○ Selectを指定していないのでいらない項目を大量に取っていた ○ タグをタイポしていてもcolumnの順番で奇跡的に取れていた The Gopher character is based on the Go mascot designed by Renée French . これ全部同じことやっているのかぁ

ご褒美 The Gopher character is based on the Go mascot designed by Renée French .

ご褒美 35% 取得遅延が 35%削減されました

ご褒美 ● ちょっと安心安全 ○ 全件削除されなくなった ○ 実行時エラーが少なくなった ○ 変な使い方がやりづらくなった ● パフォーマンス向上 ○ PreparedStatementのサポート ○ allocationが少なくなっている ● 欲しかった機能が追加された ○ contextのサポート ○ バッチインサート ○ 複数データベースや ReadWriteの分離の公式サポート ● 今ここでLTしている

まとめ ● GORMのV2の内容はとても良いので、バージョンはあげるべき ● しかし、時間がかかると想定しておくと吉 ● GORMとの付き合い方を考えるきっかけとなる ● パフォーマンスは改善されるのでやるととっても気持ちいい