adiary C76 Special Editionがコミックマーケット76にて配布されます。
8/15(土) 「東2ホール Q-02b」
詳細はadiaryユーザ会のC76ページをご覧下さい。
http://adiary.jp/C76 を参照ください。
CREATE TABLE test(x INT UNIQUE); INSERT INTO test (x) VALUES (1); INSERT INTO test (x) VALUES (2);
としておきます。
ここで、
=> BEGIN; => INSERT INTO test (x) VALUES (3); INSERT 0 1 => INSERT INTO test (x) VALUES (1); ERROR: duplicate key value violates unique constraint "test_x_key"
とするとエラーになります。PostgreSQLはトランザクション中にエラーが起こると、以後何をしてもエラーになり受け付けなくなります。ためしに続けて色々発行してみても、
=> INSERT INTO test (x) VALUES (10); ERROR: current transaction is aborted, commands ignored until end of transaction block => INSERT INTO test (x) VALUES (20); ERROR: current transaction is aborted, commands ignored until end of transaction block
こんな感じです。COMMITすると
=> COMMIT; ROLLBACK
このようにROLLBACKされます。これがPostgreSQLの仕様です。
DBD::Pgの場合
01: $dbh->begin_work;
02: $dbh->do('INSERT INTO test (x) VALUES (10)');
03: $dbh->do('INSERT INTO test (x) VALUES (1);');
04: $dbh->do('INSERT INTO test (x) VALUES (20);');
05: $dbh->commit;
とすると、3行目でエラーが起こり、4行目の実行でも"ERROR: current transaction is aborted, commands ignored until end of transaction block"といわれます。
これを、DBIのprepareを使用して
01: $dbh->begin_work;
02: $dbh->prepare('INSERT INTO test (x) VALUES (?)')->execute(10);
03: $dbh->prepare('INSERT INTO test (x) VALUES (?)')->execute(1);
04: $dbh->prepare('INSERT INTO test (x) VALUES (?)')->execute(20);
05: $dbh->commit;
とすると、3行目でエラーが起っても、4行目の実行が反映されてしまいます。謎の挙動です。
このようにソースを改変してログを取ってみました。
open(my $fh, ">pg_log.txt");
$dbh->pg_server_trace($fh);
$dbh->begin_work;
$dbh->prepare('INSERT INTO test (x) VALUES (?)')->execute(10);
$dbh->prepare('INSERT INTO test (x) VALUES (?)')->execute(1);
$dbh->prepare('INSERT INTO test (x) VALUES (?)')->execute(20);
$dbh->pg_server_untrace();
close($fh);
このときサーバに対して次のようなコマンドが発行されていました。
=> BEGIN; => INSERT INTO test (x) VALUES (10); => INSERT INTO test (x) VALUES (1); エラー : duplicate key value violates unique constraint "test_x_key" => ROLLBACK; => BEGIN; => INSERT INTO test (x) VALUES (20); => COMMIT;
どうりで最後のCOMMITが成功するはずです。取得した生ログも置いておきます。
これを、
01: $dbh->begin_work;
02: $dbh->prepare('INSERT INTO test (x) VALUES (10)')->execute();
03: $dbh->prepare('INSERT INTO test (x) VALUES ( 1)')->execute();
04: $dbh->prepare('INSERT INTO test (x) VALUES (20)')->execute();
05: $dbh->commit;
とすると再現しません。prepare中にUNIQUE制約をチェックして、勝手にrollbackしているようですが、原因がPostgreSQL側なのかDBD::Pg側なのかは絞り込めませんでした。
DBD::Pgの実装仕様みたいです。トラックバックを参考にしてください（iakioさんに感謝）。
DBD::Pgを直すとすれば、プレースホルダが破棄されてもトランザクションが終了するまでDEALLOCATEするのを待つ、くらいでしょうが。
明示的なトランザクション内でのエラーとDEALLOCATE
ROLLBACKしていいから、DEALLOCATE後に空のトランザクションを begin して、失敗させてくれればそれで十分な予感。
adairyの基盤システムであるフレームワーク（Satsuki-system）にあちこち手を入れてるのですが*1、Last-modifiedをどう扱うかで悩んでしまいまいした。
あまり知られていないことですが、adiaryは正しいLast-modifiedヘッダを返します。ネットワーク負荷削減のためには大切なことなのですが、これを正しく返すため関連するすべてのファイルの更新日時を取得し、データベース情報にもテーブル単位で同じものを入れ管理しているためプログラム負荷（実行時間）が増えているという現実があります。
大手サイトはどうしてるのかなと思いまして少し調べてみました。
あまり返さないところが多いようです。画像ファイルとかならともかく、今時テキストファイルコンテンツはあまり気にしなくて良いみたいですね。
ちなみにRFC的には
HTTP/1.1 サーバは、可能であればいつでも Last-Modified を送るべきである。
RFC2616
です。それで結構苦労して後から*2実装したのですが、Satsuki-systemを扱う上で難しくしている要因でもあるので消そうかなあ。
消しました。実装がとてもすっきりしました。
（現在配布されている）MySQLのライセンスはGPLv2であるので、クライアントライブラリとリンクするソフトウェアはGPLv2と互換性がなくてはいけないと思っていたのですが、FOSS ライセンス除外規定というものがあって、この中のライセンスなら除外規定の適用を受けて何ら問題なく使用出来るらしい。
しかし、なぜかこの中にはGPLv3が含まれない。でもって、世の中にはGPLv3でMySQLというWebアプリがいくつも存在する。*1
もうひとつ気になっているのがAGPLv3。AGPLv3はGPLv3とリンクさせる限り自由であるので、AGPLv3のアプリに対してGPLv3のソースを書いて拡張すると、AGPLv3のAGPLv3たる意味がほとんど無力化するような気がする。
そういえばmod_perlってのはApacheとリンクして動的に操作する仕組みであるので、Apache Licenseの適用を受けるんだけど、これはGPLv2とは互換性がなくて、GPLv3とApache License 2.0は互換性がある。MySQLでmod_perlなMovable TypeのGPLv2版とかどうしてるんだろう？
この記事を信用してなにか失敗しても何ら責任は負いかねます。ライセンスの確認は必ず各自で行いましょう。
Ver2.08に対し、バグ修正とメール解析ルーチンを改良したものです。
なおVer2.06よりアルバムシステム関連のJavaScriptの置き場が変更になっていますので、紛らわしい場合は theme/*.js を消してから上書きしてください。
Version2.00への移行処理を先に行ってください。