基本となるモジュールから、必要に応じた機能モジュールを拡張展開するようなヤリクチで開発を進めております。
で、運用サーバーにセットアップの際には、フル機能が動作する開発サーバーから、採用された機能分を選択的にセッティングすることになります。
っま、データベースに関しては、余分なデータはムシロ邪魔なので、初期化されたdbにテーブル作成やら外部制約やらのsql文をモジュール毎にファイルに作っておくことで、対応できますね。（システムの初期操作のための操作者は、システムに初期設定機能として、ワンクリックで生成できるようにしました）
で、システム本体、特に各コンフィグレーションも可能な限りモジュール毎に管理したいなぁ・・・と、納品完成間際のこのタイミングで、軽い気持ちで始めたら、案の定ハマッてしましました。
web.xmlやapplicationContext.xml系は、複数のファイルに分けられそうな部分を別立てにして、難なく完成。しかしハマッたのはhibernateの設定ファイルでした。といっても、分割自体が問題なのではなく、クラスの継承構造をどのように実装するか？の方法論みたいなコトで、「丁か？」「半か？」の２択しか許して貰えないhibernate君のイジワルが起因したモノでした。
mightyでは、管理する事象は大きく分けて３つです。記録の元帳に相当する、いわゆるマスター。そしてあらゆる記録（出来事）であるイベント。さらにそのイベントに関連した付随情報であるタグ（関連マスタも含む）で成り立っております。
で、この一元化されたイベント・タグにより、最大の特徴である「串刺し機能」が実装されますので、クラス構造もテーブル構造もかなり細分化されております。つまり継承のレベルが深かったり、同一構造の別クラスが多数見受けられたり・・です。
あ、今となっては、この点がキモでした。
hibernateの参考になるサイトに良く書かれているような３つの方針で、table-per-subclassを使ってマッピングしておったのですが、同一構造の別クラス・・・って、言われてみれば無駄なダミーフィールドを持たない理想的なtable-per-class-hierarchyってコトになるんですね（今に思えば）。
そろそろ核心部分ですが、table-per-subclassではマッピング定義でjoined-subclassがシバシバ採用されます。っま、追加されるデータの入ったtableと項目を足してゆく訳ですよね。対してtable-per-class-hierarchyではsubclassを使った記述でホイホイと兄弟分クラスをマッピングできちゃいます。で結果的に紛らわしいのは、このsubclassであってもjoinという記述を使えば、同じように追加されるtableと項目で子供クラスをマッピングできるんですね。ですがこのjoin君はあくまでもオマケ的なのでしょうか？SetやListが書けない。きっとcomponentを間にカマシて使えば何とかなりそうですが、そうするとクラス自体に手を加えなければならず・・・イヤです。
この地獄の混乱時点でのアセリまくった私の選択肢は以下の２つ
- joined-subclassでtable指定無しで動かないか？
- subclassでSetやListなどコレクションを入れられないか？
かなり前から、同一class定義内にjoined-subclassとsubclassは同居できないということは、書いてあり、知っており、もちろん避けていました。
仕様的にはjoined-subclassのパターンだし、discriminatorも不要だし、subclassで逃げるには工数かかりそうだし、よし、やはりjoined-subclassで行こう！！！！
結果、どうやってtable指定無しで動かしたのか？
はい、兄弟全員、親からはjoined-subclassしてますが、兄弟間では何もせずに、まったく同じ項目定義を重複して記述してあります。
ああ、カッコ悪い。
手が空いたら、hibernate関連の最新を調べたりして、このキモチ悪いのを解消しましょうね。＞自分