dbfluteとS2JDBC比較しようとおもって・・・

とりあえず、DoltengでS2JDBCのコンソールプロジェクト作ってみた。
DDL→DB→Entity生成→DDL生成→migrateタスク
みたいな流れでやったら、Migrateにて
SCHEMA_INFOテーブルのDropがエラー（最初はないので）
と、ユニーク制約のドロップのエラーでしばらく悩まされた（Entityからだと生成されるらしい）

また、いざタイプセーフにって思ったっけ、
サービスクラスにJDBCManagerがDIされない・・・

diconとか調べたりしたんだけどわからず、グーグル先生に教えていただいたら
EJB関連？jarが入っていないというちょっとわかりにくい原因だった。
ただのDIされない事による、NullPointerExceptionだし。
（この手のエラーはトラウマになるな（＾＾；）
参考：DoltengでS2JDBC利用プロジェクトを作る際の追加作業 - idesaku blog

んで、さらには、ある意味目玉の
Condition系のクラスは現在のDoltengの生成するプロジェクトでは使えないという事実。
ちまに2.4.30からの機能らしい。（Doltengが作成するのは現状.29）

先のjarについてもDoltengが次から対応するとの事なので、
それまで様子見にするか、せっかくここまでやったので、.30系のjarをかき集めてきて
進めるか・・・ですね。ちょいと文章にまとめながら進めているので
なんか例外回避やらが多いとちょっと・・・
（特に次バージョンで対応とかわかってると日和見したくなる）

それか先にdbfluteのことをまとめるか・・・なんだけど、
せっかくなので、S2JDBCを進めつつ、dbfluteなら出来るとか、対応する機能はこれだ。
みたいな感じで進めていこうかなぁと思ってるし
（dbfluteを先にすると出来ることが多すぎてまとまらない気がする）

ファーストインプレッション

今のところの感じ（生成からスキーマ管理あたり）からすると、
S2JDBC（-Gen）は、小から中の規模のプロジェクト
dbfluteは大規模系のプロジェクト
といった感想
（S2JDBCは大規模向けに作られているとの事なので、この印象がどう変わっていくのかも楽しみ。）

また、本当に第一印象だけの話だが、
S2JDBC（-Gen）は、DBチームがないようなケースで
dbfluteはDBチームがあってその管理のことも考えているといった感じ。
S2JDBCのEntityからDDLスピーディでいいとは思うんだけど、管理できるの？
というか大丈夫？という不安が大きい。（混乱する現場が目に浮かんでしまう）

10/25追記

S2JDBCとS2JDBC-Genを一緒にするかは悩みどころですが、今のところ第一候補なのは
確かですので・・・


管理方法についてはプロジェクト毎により異なるのは当然ですが、
まぁ想定される用途などからも検討できたらと。



ちなみにそれぞれ、Excel（CSV）ダンプに関して、どれくらい出せるのだろ？
POIってメモリ溜め込み系のストリーム利用してなかったっけ？
というのも試してみたいかも。

また、個人的にはちょこちょこ生成する？のかはわからないんだけど
生成物がジェネレーションギャップパターン適応されてないのも不安。
（Entityを生成するのは最初だけで、
その後は、Entityをメンテナンスしていくという方針で、
だから不要なだけ？という気もするけど）