makotan _at_ gmail dot com

やっぱりそうだ・・・

sqlP**sでログに出たSQLを実行するとデータは取得できてる。
だけど、BeanはNull
なにかしょぼいミスでもしてるのかなぁ〜
いろいろ調べていくうちにバインド変数の利用が何か影響を与えるパターンがあるような気がする
さらに実験継続・・・
実験内容
普通のDaoを準備
public String getHoge_ARGS = "hogeID";
public Hoge getHoge(String hogeID);
テストケースを準備
Hoge hoge = hogeDao_.getHoge("00001");
assertNotNull("1",hoge);
ここでエラー(T.T)
で〜も〜ね〜上手く動くやつもあるんですよ(;_;)エ-ン
唯一の違いはTableの主キーが一つはうまくいくけど、二つはだめ
とか・・・そういう違いだけ
仕方ないから
HogeDao_getHoge.sql
なんてものを作ってID直書きしてみました。ばっちり動きましたよ。
で、そのID直書きをバインドにしてみました。
nullが帰ってきましたよ・・・orz
『たすけてくださぁぁぁぁぁい!!!!!』
さらに変更しながら調査・・・
主キーの違いを確認するために主キーあり、なし、ふたつの3パターンをテスト
すべてNG
続いて、検索のキーが文字列、数値の違いを確認するために
同じテーブルに対して数値で検索するパターンを作成
結果・・・数値はOK!
確認の為テスト中・・

SelectDynamicCommand cmd = new SelectDynamicCommand(getDataSource(),
  new BeanMetaDataResultSetHandler(new BeanMetaDataImpl(
  Hoge.class, getDatabaseMetaData())),
  BasicResultSetFactory.INSTANCE);
cmd.setSql("SELECT * FROM Hoge WHERE HogeID = /*Hogeid*/'00001'");
Hoge emp = (Hoge) cmd
  .execute(new Object[] { "00001" });
System.out.println(emp);
assertNotNull("1", emp);

自分の作業中のテストケースでこんな風に書いたら予想通りnullが帰ってきた
んで、S2Daoについてるテストケースを似たように書き換えてHSQLを立ち上げてテストしたら問題なく動いた・・・( ・_;)( ;_;)( ;_;)(>0<)ワーン
上のログに出たSQLをS**Pl**で実行したらちゃんと戻りのデータはあった
S2の奥深くまでトレースの結果、PreparedStatementUtilの20行目でnullが帰ってきてる事が判明。でも、その理由は不明(T.T)

PreparedStatement pstmt = getDataSource().getConnection().prepareStatement(
  "SELECT * FROM Hoge WHERE  hogeID = ?"
);
pstmt.setString(1, "00001");
ResultSet rset = pstmt.executeQuery();
assertEquals("1", rset.next() ,true);

そして手で書いてみた・・・一番最後の行まで行って・・・エラー(T.T)
一体なんなんでしょう・・・
そして・・・かいけつ・・・してない
文字列の後にCHARと同じになるだけのスペースを入れてもNGです(T.T)
更に調査継続中
スペースを一文字減らしたり増やしたりしてたら+1文字で検索にヒット
意味わかんないよ!!
これを解決って言うのか・・・??
なんかものすごい納得できない結果・・・OracleJDBCってこの問題に対応させるために独自拡張してるんだね。
なんか細かくあっちこっちに影響する(T.T)