Mutable なエンティティモデル(1)

cube.jpで、簡単にフィールドを追加可能なテーブルについて話題が挙がっています。

http://xoopscube.jp/forum/6582?comment_id=20210

最近では 2.2 の同梱モジュールである profile に同様の機能が実装されています。

モジュールをインストールしたユーザーがある程度フィールドを拡張できれば、モジュールを色々な用途に使うことができるでしょう。あくまで MODify 行為と割り切れば、振る舞い（機能）と、その振る舞いに強く結びついたフィールドの編集をロックすることで、大まかな問題をクリアにすることができます。

これまで何度か可変テーブルに関する議論がありました。こういった技術は各モジュールでそれぞれ実装するのではなく、ライブラリとして提供され、モジュールの開発者はそれを使うだけでよい、という形をとることが望ましいでしょう。

そのうえで、主要な検討項目として、まず以下の３つを挙げることができると思います。

全モジュールを mutable なデータモデルで統一するのか、それとも選択式にするのか。
システムが提供するシステムAPIになるのか、システムパッケージが実装モジュールを提供するのか。
１レコードのコンテナ形状でテーブルを作り、 alter table でフィールドを増やすのか。あるいは eZ publish のように、動的で仮想なテーブルのみを持つようにするのか。

最近、僕のほうでは、

mutable モデルはオプション。
システム(BASE)パッケージが実装モジュールを提供、あるいは標準提供なし。
どの実装で用いられるかはどのモジュールを使うかで決まる。

という形に持っていくのが良いのではないかと考え始めています。

まず、選択式にすることで、データモデルをテーブルの完全なバインダとして扱いたい開発者のポリシーを保障することができます。パフォーマンスを重視する開発者や、SQLを使って複雑な処理をRDBMSにリクエストできる開発者には重要なことだと思います。

次に、インターフェイスと実装を分けるのはモジュール設計として当然であると同時に、適用の広さと最適化のバランスをユーザーが選択することができます。想定しているのは、パフォーマンス面で有利な alter table を用いる方式が、レンタルサーバーによっては使用できないというケースです。

仮に「誰でも導入可能」という点を重視して、 eZ publish と同じ実装を採った場合、自由度と引き換えに、モデルをまったく変更しないユーザーにも遅い動作を強いることになります。しかし、パフォーマンスを重視して alter table の実装を採れば、一部のユーザーはカスタムフィールド的なフィーチャーを一切使用できなくなるでしょう。

実装部をモジュール化すれば、ユーザーが希望に応じた実装を選択して導入することができます。

それはつまり、このデータモデルを取り扱うAPIは公約数的なものになるということです。幸い？XCのデータモデルはデータソースをRDBMSに絞らない方向で設計される予定ですので、少なくともそことの齟齬はありません。

以上は、データソース特有の操作を隠蔽したライブラリ環境下で成立する話です。ある程度 mutable なモデル定義を用いたいが、ロジック中ではガンガン SQL を書きたいという開発者は、別途ライブラリを用意したり、自前で実装することができます。

ライブラリ化するといっても、あくまでアプリケーション用ライブラリであって、ハードウェアAPIではありませんので、用意しなければ直ちに開発者から選択肢が奪われる、というものではありません。これはXOOPSファミリの伝統的な選択と言えます。

最後に少し eZ publish のフォローをしますと、 eZ publish にはページ単位の強力なフルキャッシュ機能があり、 mutable モデルのデータはそこまで頻繁に更新されないという前提で作られています。フォーラムさえ非固定なテーブルで、テンプレートでトピックを表示する仕掛けはかなり面白いです。