2015/08/29 このエントリーをはてなブックマークに追加 はてなブックマーク - とりあえずResultSet#getStringした時のPostgreSQLのjdbcドライバの挙動

とりあえずResultSet#getStringした時のPostgreSQLのjdbcドライバの挙動









いやぁ、夏なのに肌寒い日が続きますね。
そんな日はResultSet#getStringの挙動が気になりますよね。


JDBCの仕様に沿って、各ベンダーがjdbc実装をしているから、そりゃ挙動も変わってきます。
なぜかPostgreSQLの数値型をgetStringした場合の挙動を調べたのでメモがてらブログ書きます。








そもそも、ResultSetというインターフェースは
各型のメソッドgetXXXを用意してくれてるわけなので、
数値型をgetStringするのはあまり推奨されてません。

オラクルであればここらへんとか。



型変換に関しては徳丸さんの記事が詳しいと思います
SQLの暗黙の型変換はワナがいっぱい - 徳丸浩の日記


ざっくり言うと、明示的な型変換をすべし、ですよね。
あと、型にあったメソッドを使うべしですね。



なんでもgetStringするってことはjdbcドライバの実装依存となるということ。
また、型情報のハンドリングを適切にやっていないということになるのではないかと思います。




基本的にはResultSetインターフェースの仕様を守るように
各ベンダーは実装してくれてるだろうとは思いつつ。


論よりソースということで。



GitHub上でjdbc実装を公開しているんですね。
https://github.com/pgjdbc/pgjdbc

jdbc公開してるのはもしかすると珍しいんじゃないかなー。
MySQLなんかあるかな?と思って調べたらGitHub上にありました。
https://github.com/mysql/mysql-connector-j

ソースの見やすい時代になったなぁ、いやはや。

他のDB2とかSQL Serverとかあると思うんだけど、みんな各JDBCの挙動とか知りたくなったらどうしてるんでしょう。

(そんなん気にせずともORMが吸収してくれてるのがもっぱらなのかな)


さて、 AbstractJdbc2ResultSetというクラスに
ResultSet#getStringの実装がありました。

実態はというと、TimeStampは型チェックしてTimeStamp to String変換。
その他は大体各クラスのtoString実装に依存します。



つまり

SELECT -> ResultSetに格納される(多分この時点で暗黙変換されるんだと思う) → getStringで各クラス型のtoStringをリターン






ということで、結論。

・暗黙変換やめよう、なるべく明示変換しよう
・getXXXは型に合わせて使おう
・PostgresSQLは各クラスのtoStringに依存する(2015/08/29ぼく調べ)


jdbcの実装はなんだか読んでるとワクワクしますね。




0 件のコメント:

コメントを投稿