Slick3.3系でMySQLの日付型をマッピングする実装 - 3パターン実装してみたよ -
本日の配信
Slick3.3とMySQLの日付型の戦い part2 - 兎にも角にも実装するよの巻 -
今日は昨日に引き続きslickとMySQLの日付型のマッピングを実装していました。
昨日候補に上げていた
1. def * を自分で実装するパターン
2. MappedColumnTypeを利用するパターン
3. Profileを拡張するパターン
一応それぞれを実装して比較をすることまではできました〜
進捗と残タスク
進捗
- 各3種の実装比較
1-2の実装: Commit Log
3の実装: Commit Log
残タスク
- 実装サンプルの整理
- コンテンツへのインクルード
- 実際に今回採用する実装方法決め
結局のところどれがいいのか
通常の独自クラスについてはMappedColumTypeを利用するのが良いのでしょうが、今回の日付型に限ってはProfileを拡張する方法が一番良いと感じました。
今後ちゃんと記事にまとめようと思いますが、それぞれのメリット・デメリットを簡単に記載します。
ただし、あくまで私の実装した範囲においてなので、もっとよい実装方法があった場合にはこの限りではありません。
def *で対応するパターン
誰でも理解しやすくてシンプルな実装になります。
複雑なことをしていないので、何をしているのか一番理解しやすいと思います。
デメリットは今後追加される全てのテーブルの全ての日付型に対して律儀に対応しなければならないことです。
MappedColumnTypeのパターン
今回のケースでは一番旨味が少ない実装パターンになったと思います。
本来であればmapping処理を記載すると、特に自分で処理することなくデフォルトの型のように取り扱えるはずなのです。
はずなのですが、今回はこれを利用しても結局 def * の実装や、各マッピング系処理での自前実装が必要になり、無駄にコード量が増え複雑度があがりました。
自分の使い方が間違っているんですかね...
なんか他の実装だと base[LocalDateTime, java.sql.timestamp] みたいな実装も見かけるので、そのような形にするともう少しうまいこと実現できるのでしょうか？？
でもLocalDateTimeはTEXT処理されてしまうので、結局汚くなってしまうのではという気がしています。
また、さらにしんどいのが def * パターンと同じように結局マッピング周りに手を入れる必要が出てくるので全テーブルにコツコツ処理を書かないといけないです。
ここは今になって自信がなくなってきたので、いいやり方知ってる人がいたら教えて欲しいです。
Profile拡張
そもそも、これが公式で推奨されている実装方法です。
https://scala-slick.org/doc/3.3.1/upgrade.html#support-for-java.time-columns
The types are: Instant, LocalDate, LocalTime, LocalDateTime, OffsetTime, OffsetDateTime, and ZonedDateTime. If you need to customise these formats, you can by extending a Profile and overriding the appropriate methods
って、書いてあります。
今回必要なLocalDateTimeの部分だけ拡張してslickのprofileとして引き渡してあげれば、ちゃんと自分で実装したparse処理に従って日付処理をしてくれます。
なので、一回作れば他のモデルではprofileにこれを指定するだけで済みます。
初学者に対して「Profile作れ」っていうのは、結構ハードルが高いので初心者向けとは言いづらいのですが、Profile全体の説明をする必要もないので案外プログラミング経験者なら理解できるのではないでしょうか。
未経験だと、うん、しんどいとおもうけど。
というわけで、日付型に関してはこの実装方法が最適な気がしています。
ただ繰り返しになりますが、slick側でデフォルトで対応している型であり、一般的に利用される型だから、これが向いてるだけで自分で作ったクラスなどをいい感じに使う場合には通常MappedColumnTypeが良いと思われます。
まとめ
英語だからと面倒くさがってちゃんとドキュメントを読まないとこういうことになるのですね...
公式サイトにちゃんと書いてあるやないですか...
とはいえ、いや、万人にprofileを拡張しろって真顔でいうのは結構しんどい気がするんですよねぇ...
DBIOやデータアクセス周りはプロジェクトの技術強いマンがラッパー作ったり隠蔽することが多いとはいえ、slickというもの自体が相変わらず初心者にあまり優しくないなぁという思う今日のこの頃なのでした。
