生活 » Journal

SeaORM¶

• SeaORM 🐚 An async & dynamic ORM for Rust
• SeaQL/sea-query: 🔱 A dynamic SQL query builder for MySQL, Postgres and SQLite

機能 #893: fedibunker のために Rust で RDBMS をどう扱うか考えていて、いろいろ探していた。

diesel や sqlx は知っていたが、 diesel は昔ちょろっと触ったとき割と煩雑で面倒だったのと async Rust に対応していないのがどうかなといったところなので一旦スルーした。
sqlx については、 ORM 風に使おうとしたときはビルド時の DB アクセスを防ぐために開発時に DB への接続をすることで何かをキャッシュするようなワークフローがあったように記憶していて、それが嫌だったので避けたかった。
(これについては diesel でも似たような話だったかもしれないが、もう覚えていない。)
何故嫌だったかというと、プロダクション環境では postgresql を使いたいと思っていたが、開発環境に postgresql を入れたくなかったしテスト時にも要求したくなかったからである。
ステージング環境に乗せる直前までの工程は全部 SQLite でどうにかできてほしかった。

ORM 風に使おうとすると何であれ開発時の DB アクセスが必要とされそうなのであれば、いっそクエリビルダを使うに留めておいて Rust の型と RDBMS からの応答の接続は自前で用意しても良いかなというくらいの気持ちで探したところ、 sea-query を発見した。
これ自体もなかなか悪くなさそうだったが、実は sea-query が SeaORM の基盤として用意されたもので SeaORM 自体も割と良さげであることに気付いた、というのが SeaORM 発見の経緯である。

SeaORM は ORM と名がついてはいるが、 LL でありがちな「DB 上の存在として透過的に振る舞うオブジェクト」のような複雑なものを導入しなそうな設計なのがとても気に入った。
加えてコードベースができるだけ backend agnostic に書けそうな雰囲気もあるので、テスト段階では SQLite にしておいてステージング環境とプロダクション環境だけ Postgresql にしたいという要件でも使いやすい。

あとは実際に使ってみて開発時に Postgresql 対応ビルドでも Postgresql DB アクセスが本当に必要なければ上等だが、さてどうだろうか。