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

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

Version 1.3.157 (2011-06-25)

タイムゾーンとか難しいよなあとか。

  • CREATE TABLE ... AS SELECT ...のシンタックスの変更: NOT

PERSISTENTのようなオプションは、AS SELECTの前に置くようになった。そうでないと、オプションがAS
SELECT以下と解釈されてしまうため。

    • ここで言っているオプションは、ENGINE,NOT PERSISTENT,TRANSACTIONALの3つ。具体的には、前までは、
CREATE TABLE HOGE AS SELECT * FROM FUGA NOT PERSISTENT
    • だったのが
CREATE TABLE HOGE NOT PERSISTENT AS SELECT * FROM FUGA
    • となった。まぁ、そりゃそうですね。
  • バージョン1.3.156で、DB2モードではCLOB/BLOBが使えなかった。
  • 1.3.156以前から、1.3.156へデータベースをアップグレードした場合に、CLOBやBLOBのデータが多くの場合ロストしていた
  • null不可のカラムに対するCOUNT(..)の最適化もCOUNT(DISITINCT ..)となっていた。これは不正確である。
    • 原文の意図からは大きくは外れてはいないと思うのだけれど。
      • h2は、select count(*) from hogeというSQLの場合、実際の行をカウントせず、テーブル情報に記載されている行数をそのまま返すので、とても速い。
      • select count(xxx) from hoge で、xxxカラムがnot nullの場合、select count(*) from hogeに最適化できる。
      • ここまでは良かったが、select count(distinct xxx) from hoge も同様の最適化を行ってしまっていた、という問題っぽい。
  • PgServer: 非アドミンユーザがデータベースをオープンできなかった。
  • 既にデータベースがオープンしている場合、(モードが一致している場合であっても)非アドミンユーザーがモードを指定して(MODE=xxx)データベースをオープンする事が出来なかった
  • 次の例外のSQLステートが変更になった。90009, 90010, 90011 から22007に。"DATE/TIME/TIMESTAMP 定数 を解析できません"
  • サマータイムのルールが異なるタイムゾーンでデータベースファイルを開く際の問題:サマータイムのルールが異なると日時のうち時刻部分が異なる。これは同じルールで地域が異なる場合には問題にならず、さらにタイムゾーンが異なっていても問題にならない。回避方法は、データベースを元のタイムゾーンSQLスクリプトとしてエクスポートして、新しいタイムゾーンで新しいデータベースを作る事。同様の問題が、TCP/IP越しでクライアントとサーバーが異なるルールを使っている場合についても発生する。