H2Databaseを追っかけていたりしたブログ

H2 database のリリースノートを読んだりとか。

Version 1.3.160 (2011-09-11)

結構細々不具合あるものですね。

  • 計算列で自分自身を参照できなかった
    • 下記のようにかけなかったようです。
sql> create table hoge (id int, txt varchar);
(Update count: 0, 4 ms)
sql> alter table hoge alter column id int as id + 1;
Error: org.h2.jdbc.JdbcSQLException: 一般エラー: "java.lang.NullPointerException"
General error: "java.lang.NullPointerException"; SQL statement:
alter table hoge alter column id int as id + 1 [50000-159]
  • Issue 340: "x = all(select ...)"やそれに類する比較を中で使っているビューやサブクエリをテーブルとして扱うと正しくない結果が返る
    • 以下、1.3.159での結果。160だと最後のカウントは正しく2件となる。
sql> create table test(name varchar(255));
(Update count: 0, 4 ms)
sql> insert into test values('a'), ('b'), ('c');
(Update count: 3, 7 ms)
sql> select name from test where name > all(select name from test where name<'b');
NAME
b
c
(2 rows, 86 ms)
sql> select count(*) from (select name from test where name > all(select name from test where name<'b')) x;
COUNT(*)
1
(1 row, 19 ms)
  • "x = all(select ...)"やそれに類する比較がいくつかのケースで正しくない結果を返す(例えば、サブクエリが結果を返さない場合、複数の行が同じ値を返す、nullになる、xがnullだった場合)
    • 後ろの方良くわからない
  • Issue 335: DROP ALL OBJECTS DELETE FILESをCLOBやBLOBを持った以前のデータベースに対して実行できない。この問題は、いくつかのケースでメタデータテーブルがロックされておらず、そのため、LOBストレージがアップグレードされているデータベースでロールバックがデータベースの不整合を引き起こす事による。
  • //##を使っていたソースコード切り替えが簡素化された。Java 1.5 tagはもう必要ないので削除された。
  • JDBCのメソッド、PreparedStatement.setTimestamp, setTime, 及び カレンダーを伴うsetDate, ResultSet.getTimestamp, getTime, 及び カレンダーを伴うgetDate で間違った方法で変換してしまっていた。そのため、いくつかのtimestampの値が不正なものとなっていた(夏時間に切り替わる最初の一時間)
    • 最後の箇所は原文では(where summertime starts, one hour per year). あんまりよくわかりませんが、ここらへんしばらくサマータイム関連の修正が続いている感じですね。
  • 'order by'の中に無効なテーブル名があっても検出されないケースがあった。例) select x from dual order by y.x
    • 159だと何事もなかったようにスルーされます。下は160での結果。
sql> select x from dual order by y.x;
Error: org.h2.jdbc.JdbcSQLException: 列 "Y.X" が見つかりません
Column "Y.X" not found; SQL statement:
select x from dual order by y.x [42122-160]
  • Issue 329: CASE式: データタイプの問題が検出されていなかった
    • ちょっとIssueの方を見てもよくわからなかった。caseでnullを返す場合の型の問題?
  • Issue 311: File lock mode serialized: シーケンスからのnext valueの取得がポーズ後は正しく動作していなかった。データベースがそれをリードオンリーのオペレーションとみなしていたため。
    • ポーズ後? 途中に再接続チェックが入った?