ConditionBeanでもselectCursor()

@DBFlute, Java
> (DBFLUTE-428){Java}:
> ConditionBeanでもselectCursor()

大量件数検索時のメモリ対策の機能をConditionBeanでも
出来るようになりました。
memberBhv.selectCursor(cb, new EntityRowHandler<Member>() {
    public void handle(Member entity) {
        // 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よりも速い」
ということを覚えておいて下さい。