@DBFlute, Java
> (DBFLUTE-428){Java}:
> ConditionBeanでもselectCursor()
大量件数検索時のメモリ対策の機能をConditionBeanでも
出来るようになりました。
memberBhv.selectCursor(cb, new EntityRowHandler<Member>() {
public void handle(Member entity) {
}
});
BehaviorPlatinumTestにもExample実装があります。
外だしSQLのカーソル検索との違いは、
Entityへのマッピングコストが存在するというところです。
外だしSQLのカーソル検索は、(ラップされた)ResultSetを処理
CBのカーソル検索は、マッピングされたEntityを処理
大量件数時には、この差が大きくなることがあります。
例えば、50万件処理するとか100万件処理するとか。
なので、厳密なパフォーマンスを要求する場合は、
外だしSQLのカーソル検索をご利用下さい。
もともとこのことがあったので、CBのカーソル検索は
実際の現場であまり必要性がないと考え、サポートして
いませんでした。しかしながら、
「1万件くらいなのでメモリ対策OKならマッピングコストは割り切る」
という場面もあるのと、
「DBFluteはリフレクションレスでマッピングコストは低い」
という要素を考え、サポートすることに決めました。
ちなみに、このことを「CBよりも外だしSQLの方が速い」と
単純な捉え方をしないように気をつけて下さい。
外だしSQLのカーソル検索が速いのは、
外だしSQLだからではなく、ResultSetから直接取得するからです。
外だしSQLでもマッピングしたEntityを処理するやり方であれば、
CBのカーソル検索と同じです。しかし、その機能こそ必要性が
ないので、サポートしていないというところです。
構造的にまとめるとこうなります
ConditionBean
o ResultSet(マッピングなし) → なし(※1)
o Entity(マッピングあり) → CBのカーソル検索
OutsideSql
o ResultSet(マッピングなし) → 外だしSQLカーソル検索
o Entity(マッピングあり) → なし(※2)
※1: タイプセーフ解決ができないので(必要性がないので)サポートしない
※2: 外だしSQLカーソル検索を使えばよく必要性がないのでサポートしない
外だしSQLカーソル検索が特別に速く、
「こいつはConditionBeanや通常の外だしSQLよりも速い」
ということを覚えておいて下さい。