DBFlute よりも早く ConditionBean が 5 周年を 迎えました。ってどういうことかというと、 DBFlute はその名で世に出る前に、DaoGen(だおじぇん) という 名前で存在していました。その中で ConditionBean は誕生しました。 5年より前にも ConditionBean という名前はありましたが、 それは今のものとは全く別ものだったと言えるでしょう。 5年より前のCB = S2Daoの「DTOによる検索」の拡張 5年前からのCB = DBFlute の ConditionBean ConditionQuery が導入されたこと、そして、自前でSQL文字列を 組み立てるようになったこと、これらが大きなターニングポイントと なりました。それまでは、あくまで拡張。そして拡張ギャップから、 問題が幾つかありました。 o ソースコードの膨張(カラム数が多い、FK数が多い) -> 今より遥かに膨張率が高く、開発に明確な支障が出るほど コンパイルが遅くなってしまいやすかった o IFコメントの嵐で解析時間が長い -> 全てのパターンのIFコメントが生成されるので、 OGNLの処理コストが半端じゃなかった o FK先を全て自動で結合してしまう -> S2DaoのSQL自動組み立ての仕様 使える状況では便利に使えるのですが、ちょっと内部的に乱暴なロジック なので、大きなテーブルになるとつらいもので、個人的には失敗かと。 拡張って難しいものです。拡張される側が想定していない拡張をすると、 論理的にはつじつまが合っていても、どこかに拡張ギャップが生まれて、 意外なところに落とし穴があるものです。まさにそんな感じでした。 で、年末仕事納めをして、夜10時スタート、Velocityテンプレートを 分解して(一度分解すると、わけわからなくなるので途中で止められない)、 できたのは朝8時頃。ずっとカウンターに PC を置いて立ちっぱで実装。 今ある ConditionBean は 5 年前の今日、生まれました。 恐らく今の時間まさしく実装中だったような... (正確には覚えてないんだけど、仕事終わった直後あたりの日だったはず) 個人的には、DaoGenを作りながらもそれを使ったプロジェクトには 特に入っていなくて、別のかなり忙しいプロジェクトしていたもので、 「自分が DaoGen に専念させてくれれば幾らでも解決するのにぃ」 と、若気のいたり的な思いでありながらボランティアOSS活動に常に つきまとうジレンマ、に襲われた初めての瞬間(まだOSSじゃないけど)、 かなりうっぷんがたまっていたのでしょう。その思いが実装に爆発した という感じですね。 o ConditionQuery でFK先テーブルの条件メソッドを再利用 o 自前でSQLを組み立てる (当時は完全ではなかったのですが) o SetupSelect の導入で取得するFK先は選択制に これにより問題は解決し、DBFluteの歴史を一歩踏み出したと 言っても過言ではないでしょう。できたばかりの ConditionBean は、 今よりも遥かに未熟で、とても完璧なものとは言えませんでしたが、 「S2Daoの自動生成ツール」から「DBFlute」へ。 その瞬間だったかなと今でも思っています。
