ORM
ここではScala専用のORマッパをさぐってみる。
ORマッパに求めるもの
- XMLがないこと。XMLでの設定は論外。すべてをScalaで記述できること。
Criteriaが存在する場合は簡単記述でなければならない。Hibernateは論外。
HibernateのCriteriaを使うくらいならSQL直書きのほうがはるかにまし。しかもHibernateは遅すぎる。- ORマッパそれ自体が拡張可能でなければならない。
最後の点は特に重要。一般にライブラリやフレームワークの作者は「自分の使い方の範囲」で便利なように作成してしまうが、これはもちろん間違い。自由に拡張可能でなければならない。これはScalaのScalabilityと同様の意味である。Scalaはそもそも、それを目指しているのであって、そのパワーを削ぐようなライブラリやフレームワークは意味がない。
具体的に言えば、以下のような拡張ができなければならない。
フレームワークがサポートしていないとしても、コード上のスキーマ定義から、自動的にデータベース生成SQL(DDL)が生成されなければならない。
もちろんこれは、RDBによって異なるものであるが、それを「アダプタ」としてユーザが提供できるような仕組みになっていなければならない。
コード上のスキーマ定義とは別途DDLを手で入力しなければならないものなどは論外。- 上記と同様であるが、既に存在するデータベースのスキーマとコード上のスキーマが一致しているかを検証することのできる仕組みが必要。もちろんこれもRDBの種類に依存するが、それを記述できるように（各RDB用のアダプタを記述できるように）なっていなければならない。
- ただし、スキーマの変更に際しては、差分のDDLを手で記述することはやむをえない。
外部キー定義ができなければならない。あるいは、外部キーではないにしても、キーの参照が表現できなければならない。
外部キーによってテーブル間の論理的な整合性は保たれるが、都合によっては明示的に外部キーとはできない場合もある。その場合にも、コード上のスキーマには関連を定義できれば、それによってプログラマティックに整合性を検証することができる。
以上のような拡張性の有無が、これからのORマッパの有用性を決めるのであって、これらに比較すれば「CriteriaでタイプセーフなSQLを作成」などの宣伝文句はどうでもよい。タイプセーフのために、書きやすさ・わかりやすさが犠牲になるのであれば、タイプセーフの方を捨てる方がよい（念のために書けば、これはSQL文字列が極めて小さな範囲しか占めず、データベースのリファクタリングの必要は比較的少ないことに起因する。タイプセーフな言語とそうでない言語を比較しての主張ではない。何ごとも「規模」が肝心）。