[seasar-s2dao-dev:93] Re: Next S2Dao - PagingのDBMS機能使い切り

[kubo]

久保です。

あけましておめでとうございます。


> > Pagingは、Hibernateのように、DBMSの機能をできる限り
> > 使い切る。
> 
> ここを切望します。
> 現状だとOracleのPagingを高速化しようと思ってもResultSetFactoryが
> SQL文を知らないのでどうにもならないのです。

ここの議論を活発化するためにも参考程度ですが、
コメントさせて頂きます。


DBFluteでは以下のような方法で実現しています。

ConditionBean(SQL自動生成)の場合：
  baseのSQL文を豪快に select * from ([baseSql]) where romnum...
  という風に囲っています。
  S2Daoの仕様が、「結合先の列の識別」をalias名にRELNOを付与することで
  実現しているために、自分Tableと結合Tableで同名の列があっても
  正常にEntityに値がMappingされます。(逆にRELNOに助けられた)
    ※Apache Torque の LargeSelect はこの点がダメだった...

外だしSQL(SQLファイル)の場合：
  開発者が自由にSQLを書くため、逆に安易に select * from (...)と
  囲ってしまうのに不安があるため、
  「ROMNUMを利用することも2WAY-SQLとして明示的に記述」
  してもらうようにしています。
    →select * from ([baseSql])
       where rownum > /*pmb.pageStartIndex*/20
         and rownum <= /*pmb.pageEndIndex*/40
  この場合SQLファイルがDB依存してしまいますが、
  Pageサイズや取得範囲の計算を隠蔽するだけでも
  十分メリットがあるかなと思ったのと、
  これ以外の良い方法を思いつかなかった次第です。



S2Pagerは、SQL自動生成なのかSQLファイルなのかは
特別に区別付けていない作りだったと思いますので、
上記のようにはいかないのと、今からそのような方針に転換するのは
できないかと思います。(すいません参考にもならないですね...)

なのでやはり、PagerResultSetFactoryOracleRownumWrapper みたいな
クラスを作っていく方向になるのかと思います。
単純に select * from ([baseSql]) where romnum...
と囲ってうまくいくかは何も検証していないのですが、
やはりSQLファイル利用時に世の中の全てのSQLでうまくいくかは
不安な点があります。
  →現状既にS2Pagerを使って、SQLファイルでPagingしている人が大勢
    いるかと思います。それらSQLがError無しで正常に動作する互換性が
    ないとマズいですよね...




> ありますが、limit,offsetを使えないRDBMSは現行どおりResultSet取得
> 時にPagingすることになるので、ResultSetFactoryに相当するインター
> フェースにSQL文とバインド変数とPagerConditionを渡せるようにするの
> が一つの解かと思います。

すいません、これちょっとよくわからなかったのですが、
このやり方がOracleのRownum対応の一つの解ってことですよね？
（具体的なイメージが掴めませんでした。すいません。。。）



-- 
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
kubo   <jazzflute ＠ mbn.nifty.com>
jflute <http://d.hatena.ne.jp/jflute>
株式会社ビルドシステム <http://www.buildsystem.co.jp>
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/