Perlゼミ

DBIx::Customの5年前に廃止予定にした機能が取り除かれます

僕はDBIx::CustomというORマッパーを作っているのですが、5年以上前の初期開発の記事に、廃止予定にした機能を取り除く作業を今行っています。

たくさんのソースコードの修正があるので、新しいリリースが行われるときは、十分にご注意ください。

今後の方針としては、互換性を崩さずに安定的に運用される予定です。

速さに注目したDBIx::Custom::Fastを作りたい

一方で、モジュールの複雑さとパフォーマンスに関して、いくつかの不満があります。

たくさんのオプションが存在するので、それに関してすべて条件分岐しているので、その分パフォーマンスが遅くなっています。insertを繰り返す、fetchを繰り返す部分は、それらの条件分岐は取り除きたい。

複雑さに関しては、いくつかの煩雑さを感じていて、だれが使ってもわかる程度に、最小限のメソッドとオプションに抑えたい。

運用してきた感覚としては、ORマッパー側にフィルタをいれるというのは、煩雑でわかりにくくなる。ORマッパーを利用する側のフレームワークでAPIを書いたほうがわかりやすく感じる。たとえば、日付の変換は、データベースのフォーマットでもらってきて、HTMLの中でフレームワークのAPIで変換するほうがいいかなと思う。

DBIx::Classにあるのようなインフレートとデフレートを当初は考えていたけれど、この実装は対称性が非常に悪く、RDBMSにも依存する。

対称性が非常に悪いというのは、データベースに入れるときは「列名」で、判定しないといけないのだが、データベースから取り出すときは、「データ型」で判定しないといけない。そして「データ型」はRDBMSに依存する。

たいていの場合は自動的なフィルタリングか書かれてば良いと思っていたが、実際にアプリを書くと、フィルタリングをしたくなくってデータベースのデータをそのままもらいたいという場合も多い。

そう考えると、ORマッパー側に実装しないほうがわかりやすいなと。多少面倒でも、変換処理を手で書いた方が理解はしやすい。

利便性とわかりやすさのトレードオフだけど、僕の自分の趣味としては、わかりやすいほうに動きたい。

DBIx::CustomとDBIx::Custom::Fastを両方運用するような感じでスタートしようと思う。DBIx::Customは仕事で使って、DBIx::Custom::FastはGitPrepと新しいプロジェクトで使ってみようかなと思う。

最近は新着記事をあまり書いていなかったのだけれど、今年は、定期的に書いていきます!

思い立ったら書いていた、初期の感じに戻ります!!!