プロダクトとしてではなく、ツールとしてdbfluteを使用する(Tableいっぱい編)。とそこから発展
前提
プロダクトとして、dbfluteは導入できないけど、
タイプセーフなSQLを作るためのツールとしてdbflute使ってみよう！という話。
※ログからSQLをひっぱって流用するのを想定
はたして便利なのか？
最近のツールは賢いぞ！
と思うものの、いや・・・自分SQL苦手ですから・・・
UPDATE文とか時々空で書けないですから・・・
というレベルの人にとっては光明となるか！？
まぁ面白そうだということでチャレンジしてみた。
導入や生成なんて、それこそ小1時間もかからずに出来るんだが、
いかんせん、メリット兼デメリットである「コードジェネレータ」という点が、
大量のテーブルを抱えるプロジェクトではネックとなる。
- includeQueryMap.dfprop
- table.except.list.dfprop
を駆使して、生成リソースを減らすものの、どうしても限度があり、
（そもそも、使わないというテーブルなんて、明らかに使わないとかレベルじゃないとこの段階では絞れないフェーズを想定）
この段階で5000を超える生成物があり、
テスト実行時などに非常に動作が重い。
マシンがしょぼかったりするせいもあると思う。
よし！いっそ、生成したらjarにしてしまおうという発想！
対処内容
build-[project].xml
の設定で、ソースディレクトリ以外に出力されるようにする。
torque.java.dir = ../gensrc
build.xmlを用意する。
内容はこんな感じ。（実物は後ほど）
ツールとして利用するdbfluteとしては、
生成物に手を入れることはないと思うんだけど、
一応手を入れられる手段を用意しておく。
純粋なsrcではないソースディレクトリを用意するとよいかも。
今回はsrcにそもまま配置してしまう。
結果
生成されたjarをlibに配置して、クラスパス通して、
テストクラス用意して、
Queryは「投げずに」、cb.toDisplaySql()とかで、SQLを取得。
うーん快適だ・・・
これが、ソースディレクトリに生成ソースが入っていたときとかだと、
気がつくとeclipseがお亡くなりになっていたりしたのを考えると、
build時だけのストレスで済むのは大きいですね。
あとは、SQLの大文字縛りとかだったら、toUpperかませたりして（そんなオプションもありそうだけど）、
エイリアスが「dbflute」なのを置換したりすればきれいな「正しい」SQLの完成です。
（この置換でバグが潜む可能性があるのはいただけないですけどね（＾＾；）
さーてどうなんだろうね。これがいいことかはご自身の手で確認してみてください。
僕なんかからすると、少なくとも、
SQL書いているというより、
コード書いているという感じがストレスフリーです。
そして、プロダクトとして利用しようよ。。。という思いがストレスフル。
以下buildファイル
クリーンビルド(デフォルト)と
差分ビルドと、
一応後始末タスクを適当に使い分けてください。
テーブル数が少なければ、全部デフォルトでいいと思いますが・・・
