SQLJの壁を1つ乗り越えた(sqlj.runtime.Scrollable)

sqlj.runtime.Scrollableなイテレータ宣言の仕方。
DB2のマニュアルを信じていたのに、マニュアルではない書き方が必要。

sqljエディターの右クリックのコンテキストメニューより「SQLJアシスト」を使う。
まずこの時点でRational Appilcation Developerでも入ってないと厳しい。

#sql public iterator TestItr implements sqlj.runtime.Scrollable with (holdability=true,sensitivity=sqlj.runtime.ResultSetIterator.SENSITIVE, dynamic=true) (String COLUMN_A);

DB2のマニュアル通りにsensitivity=SENSITIVEと書いていては動かない。
また、この書き方をするようになって、イテレータ属性の中のdynamic指定がSQLJ仕様にないと言われることはなくなった。

SQLJアシストからのウィザードに従う中で、「ユーザーインターフェース」を追加することも可能だが意味がない。
#sql public iterator TestItr implements sqlj.runtime.Scrollable,UserInterface with (holdability=true,sensitivity=sqlj.runtime.ResultSetIterator.SENSITIVE, dynamic=true) (String COLUMN_A);
つまりは複数のインタフェースを書けるのだが、Javaソースは自動生成なので未実装で怒られることうけあい。
これでユーザーインタフェースを追加する場合は、以降は自動生成に頼らないのが前提だと思う。

ちなみにこの記述はNamedIteratorでもある。
末尾に(String COLUMN_A)と書いてる部分でそのように認識される。
これはTestItr型な変数itがあるとして、
String a = it.COLUMN_A();
と書けるようになる。
it.getResultSet()したものを引きまわす場合は、NamedIteratorにする意味は無いと言って良い。

ちなみにsqlj.runtime.NamedIteratorはマーカーインターフェースです。
(String COLUMN_A)のCOLUMN_Aは、TestItrクラスにCOLUMN_Aアクセサーを作れという内容に変わる。

さきほど「ユーザーインタフェース」の話を書いていたが、implementsではなくextendsを書けないのは理由がある。
sqljの自動生成の裏側でextendsを使ったコードを生成するからだ。

あと、これまで以下が受け付けられなかったのは、intとして指定されることだからなのであろう。
#sql public iterator TestItr implements sqlj.runtime.Scrollable with (sensitivity=SENSITIVE) (String COLUMN_A);
sensitivityはintなので、文字列が来たら解釈出来んってわけ。
#sql public iterator TestItr implements sqlj.runtime.Scrollable with (sensitivity=1) (String COLUMN_A);
のようにintベタ打ちであれば解釈されたが、自分が作ったint定数を入れると受け付けてくれない。
なんだか色々不思議な制御がされているということだな。

また、やはり明らかにsensitivity指定しないデフォルト値がINSENSITIVEというマニュアルの記述は誤りで、
sqlj.runtime.ResultSetIerator.ASENSITIVE(=1)が返ってきていて、ResultSet的にはTYPE_FORWARD_ONLYとして扱われる。