Oracle LONG for Java

IT

http://rryu.sakura.ne.jp/nisenise-fuhito/200402.html#000177
http://rryu.sakura.ne.jp/nisenise-fuhito/200402.html#000178
JavaにおけるOracleのLONG型の扱いについて。

OracleではVARCHAR2の最大サイズが、4000バイト。よりでかい文字列カラムを作りたいときは、LONG型を使う。
だが、このLONG型の制限が、いろいろある。
中でも最も痛い制限は、LONG型の列は１表に１列のみということ。

今はLOBを使うのがよくってよ？

JavaからLOBの扱い

システムを、HiRDBからOracleの環境にポーティングしたい。
だが、OracleのVARCHAR2は4000バイトまで。HiRDBのVARCHAR(32000)定義列を素直に移植できない！
そこで前任者が間に合わせ的にとった手段はZIP圧縮。

String→バイト配列→ZIP→StringでVARCHAR2へ格納。

むろん、32000バイトの文字列がZIPで必ず4000バイト以下に圧縮できる保証はないので、データサイズによって動いたり動かなかったりする。

確実にやるには、HiRDBと同等かそれ以上に大きな文字列を格納しなければいけない。
LOBである。

http://java-house.jp/ml/archive/j-h-b/052267.html#body
http://java-house.jp/ml/archive/j-h-b/052271.html#body

　OracleのBLOB/CLOBは、そのカラムの中にデータが格納されるのではなく、カ
ラムには、そのデータがあるポインタが格納されるものと考えられます。これを
LOBロケータと呼ぶようです。
　なので、挿入・更新時には、まず「empty_blob」で、カラのBLOBを示すロケー
タをカラムに入れます。
　で、実際にBinaryなLarge Objectを格納するには、このロケータをSELECT文で
取得し、得られたBlobオブジェクトをOracleのBlobクラスにキャストして、そこ
でストリーミングでデータを連続して送るという処理になります。
　なお、このSELECT時に、SELECT FOR UPDATE構文で、取得と同時に行ロックし
ないと不都合がある場合があるらしいです。（トランザクションによる？）

　J2SE1.4のAPIリファレンスを見ると、setBinaryStreamなどのAPIは1.4からの
サポートとなっています。それ以前には、そもそもBlobクラスにはデータの入出
力できるメソッドがなかったはずです。（おそらく、RDB依存性のため？）
　したがって、かつてはJ2SE APIだけではOracleのBLOBは扱えなかった、といえ
ると思います。（このJ2SE1.4の新しいメソッドは試したことがないので、どれ
だけ使えるのか未知数ですネ。）

ソースはKodersで調べたら
http://www.koders.com/java/fid24D3B435DE56FF0462576C71BD3C72DFFC811E84.aspx
http://www.koders.com/java/fid9F4E6140BB118130437F9D303475180B1F0E55E7.aspx
あたりがサンプルになりそうな。