谷本 心 in せろ部屋 このページをアンテナに追加 RSSフィード

2007-10-30

[][]ストアドの呼び出し方の希望。

今のS2JDBCのやり方の通り、ストアドプロシージャ/ストアドファンクションごとに

Entity(Parameter)クラスを作るというスタイルで構わないと思います。


public class FunctionParam
{
	public String result_OUT;

	public String arg1_IN;

	public String arg2_IN_OUT;

	public String arg3_OUT;
}

ただ、こんな変な命名規則だけでなく、アノテーションで書けると、ちょっと嬉しい。

public class FuncParam
{
	@Out
	public String result;

	@In
	public String arg1;

	@InOut
	public String arg2;

	@Out
	public String arg3;
}

こういう感じね。


まぁ、命名規則だろうがアノテーションだろうが構いませんが、

肝心のストアドの呼び出し方は、

jdbcManager.callFunction("hogeFunc", param);
jdbcManager.callProcedure("hogeProc", param);

みたいに書ければ良いと思います。


ストアドファンクション (callFunction) の場合だったら、

一番最初のパラメータを、必ず戻り値だとみなせばOKだし、

ストアドプロシージャ (callProcedure) の場合は、

全てを引数扱いにすればOK。


それだとちょっと間違いそう、、、と言うなら

public class FunctionParam
{
	public String result_RESULT;

	public String arg1_IN;

	public String arg2_IN_OUT;

	public String arg3_OUT;
}

こんな風に、RESULTパラメータとして

明確にすれば良いのではないでしょうか。


こうやって定義しておけば、

jdbcManager.callFunction()を呼び出した時点で、

引数パラメータにRESULTがなければエラーとなります。


それで上手く行きそうなのですが、どうでしょうか。

[][]ストアドの呼び出しって、RESULTは戻り値にしたいんだけどねぇ。

ホントは、callFunctionの場合には、戻り値をちゃんと返して

public class FunctionParam
{
	public String arg1_IN;

	public String arg2_INOUT;

	public String arg3_OUT;
}

String result = jdbcManager.callFunction("hogeFunc", param);

みたいに出来たら嬉しいのですが、

ちょっと夢が溢れる系なので、Irenkaでもなきゃ無理かなw


そもそも、戻り値云々の話を考えた場合、

ストアドファンクションそのものをJavaのメソッドとして定義する、

S2Dao形式の方が、定義しやすいかも知れませんね。

public class FunctionParam
{
	@ProcedureParameter(ParameterType.IN)
	public String arg1;

	@ProcedureParameter(ParameterType.INOUT)
	public String arg2;

	@ProcedureParameter(ParameterType.OUT)
	public String arg3;
}

public interface HogeDao
{
	@PROCEDURE_CALL("hoge")
	public String callHoge(FunctionParam param)
}

これだったら、戻り値のキャストも不要ですよね。


ストアドプロシージャ、ストアドファンクションだけはS2Daoを使う

、、、というのも何だかなー、とは思いますが、選択肢としてはアリなのかな。

2007-10-29

[][]続・JdbcManagerで〜

釣った魚には餌をやらない、

そんなあんたに惚れたあたしが悪い、

cero-tです。


いや、実案件で投入するためにも

私はきっとs2jdbc-codegenとかs2jdbc-makerみたいなのを作るでしょうけど。

[][]JdbcManagerのストアド関係

生でストアド呼び出してるのと、変わらないからいいんですよ。何をやっているかが一目瞭然。そして、余分なJDBCまわりの処理はする必要がない。

2007-10-26 - ひがやすをblog

「何をやっているか」は、ストアドプロシージャの

名前だけ書けば一目瞭然だと思いますし、

何よりストアドの呼び出し部分って、バツグンに誤記しやすい。

だから自動生成してくれるに越した事はない。


とは言え、

Oracleのストアド周りのメタデータ呼び出しが最悪に遅いし、

流れるように書こうと思っても、なかなか上手くできない。

(koichikさんも書いている http://d.hatena.ne.jp/koichik/20071026#1193396407 通り)


やっぱり、

理想はあくまで「ストアド呼び出しSQLは自動生成」であって

それを実現する手立てが見つかっていない状態だと思いますが。


うーん、

みたいな?


イマイチ・・・。

ひらめきを待とう。

[][]JdbcManagerのレビュー関連

何でもJavaで書こうとすればきっとはまると思いますよ。でも、S2JDBCはそうじゃない。

  • from()
  • join()
  • where()
  • orderBy()
  • limit()
  • offset()

でかける範囲に限定して自動でSQLを生成し、それ以外は、明示的にSQLを書けというスタイルです。

上記の6つだけで構成されているなら、レビューはしやすいと思いますよ。

2007-10-26 - ひがやすをblog

うーん、whereがないとか、whereがごく簡単なら、

レビューできると思います。


ちょうど、QUERYアノテーションがもうちょっと賢ければ、

と思っていた所に手が届いた感があります。

(それでも「S2JDBCの方がSQLより」レビューしやすいか、と言われると疑問ですが)


ただ、問題はwhereでしょう。

SimpleWhereも「Javaで書ける範囲」に該当するとは思いますが、

leとかeqがいっぱい出てくるJavaSQLは、レビューしたくないでしょう。


書く方も、SQLJavaの脳内変換をしながら書いて、

読む方だって、JavaSQLの脳内変換が必要になっちゃう。

だからせめて、JavaSQLを変換する機能が、IDEに欲しいわけです。


そこまでするなら、書く方も読む方も、SQLで良いじゃん?

というのが今のところの感触。


まぁ、実際に使ってみよう>自分

2007-10-25

[][]JdbcManagerで生産性10倍ってさー。

http://s2container.seasar.org/2.4/ja/s2jdbc_abstract.html

タイミング的に、今しか言えなさそうなので。


生産性を10倍以上高めることを目標として

何をもって10倍と言うのか、、、と思ったんだけど、


何に比べて生産性が10倍かというとJava標準のJPA(Java Persistence API)に対してです。

相手が悪い。

JPAと比べてどうするのって思う。

(マネージメント層の説得のために、JPAと比べたいのかも知れないけど)


JPAと比べるせいで

「やっぱS2Dao捨てちゃったんだ」って思うのが、私の感覚。


S2Daoの問題を見直して、S2Daoに比べてこれだけ生産性を高めた」

って言ってくれる方が、S2Daoのノウハウが積み重なった感じがして、嬉しいんだけど。


■INSERT/UPDATE/DELETE系

S2Daoでは分かりづらかった命名規則がなくなった分、

良くなったと思う。素直に嬉しい。

ハマらなくなったし、調べなくて良くなった。


■ストアドの呼び出し

jdbcManager.callBySql("{? = call myproc(?, ?)}", dto).call();

さすがに、これはダメだろー。

生でストアド呼び出してるのと、変わんないじゃん。

(実際そうなんだろうけど)


「?」の数の間違いを検出してくれる機構よりも、

S2Daoと同じ感覚で、

jdbcManager.callProcedure("myproc", dto);

jdbcManager.callFunction("myproc", dto);

ぐらいで、呼び出し文を構築してくれる方が分かりやすい。


だって、「?」の数は間違うことはあっても、

Dtoに記述したIN/OUT/IN_OUTは間違わないから、きっと。


あと、個人的には、stored functionは

「return_OUT」を、「戻り値」にした方が、

分かりやすいと思うんだけど。

戻り値にできない(or したくない)理由って何かあるのかな?


■検索系

多分、今回の目玉だろうけど、

肝心のこれで、生産性が上がると思えないんだよね。


> 90%のSQLを自動生成する

自動生成と言っても、JavaSQLを書くんでしょう?


私は、このJavaSQLが、いまだにダメで。

新人の時に、Hibernateで大失敗して以来、トラウマで(←自分が悪いw)


要は、SQLも分からんのに(SQLドリルが終わってないレベルで)

Javaでホイホイ作ってると、とんでもない実装しちゃうじゃん?


別に、SQLドリルをちゃんと終わっていて、

JdbcManagerが吐くSQLをきちんとイメージしながら作っていれば

間違わないと思うよ?

でも100人開発者集めて、開発をスタートさせたら、

そういうわけにはいかないよね?


だから、limit(10).offset(100)を書かせる。

だから、SQLを書かせる。


どっちにすべきかは、よく考えなきゃいけない。

いまの私の考えだと、後者かな。


あと、SimpleWhereみたいなJavaSQLって、

たぶん、高速に書きたい or 高速にリファクタしたいがために

JavaEclipseを活かして書くってことだよね?


私自身、高速リファクタの恩恵を受けた経験がないから

まだ良さに気付いていないだけかも知れないけど。


それでも、

SimpleWhereを書くぐらいなら、素直にSQLを書いた方が

SQLをきちんと理解できるし、何より、レビューしやすいと思うんだけどね。


■レビューできない

そうなんだよね、

JavaSQLのソースなんてレビューできないんじゃん。

生のSQLを見なきゃ、レビューできないじゃん。

少なくとも、私の右脳は、JavaSQLから問題を発見できない。


ソースコードを右クリックしたら、SQLが表示されるEclipseプラグインとか、

JdbcManagerの呼び出し箇所を検出して、全てのSQLを表示してくれるツールとか、

そういうのがなきゃ、レビューできない。

(そんなツールが構想に入ってないようだったら、作るよー!)


で、レビューした結果NGだったとして、

それをJavaSQLでどれだけ簡単に修正できるかも、まだよく分からない。


この辺りは今後評価していきたい。

2007-10-19

[]jdbcManagerをどこで呼ぶの?

http://d.hatena.ne.jp/higayasuo/20071019#1192768675

なるほどー。

JdbcManagerってstaticで呼び出すとばかり思っていたので

  • ServiceからJdbcManagerを呼ぶように作ったら、ServiceのJUnit実行時にDBが必要になってメンドイよなー
  • かといってDaoを作ってJdbcManagerを使うコードを記述するのも、なんだかなー

なんて思ってたんですが、

jdbcManagerはDIされるんですね。

だったらMockと簡単に差し替えられますね。


ま、とはいえ、Daoクラスを作っても良いと思うのですが。

自動生成(動的生成)の都合とか、SQLレビューの都合を考えれば、

Daoが分かれている方が、嬉しいことってあるでしょ。

[]jdbcManagerさんにお願い

最後にtoSqlString()メソッドをくっつけたら、

生成したSQL文を返してくれるようにして欲しい!(><)


SQLのレビューをする時に便利だろうから!