スレッドメモ

◆ [fj][fj.comp.lang.c] デバッグ文（可変引数マクロ）Ｃ９９ 仕様

<3988628news.pl@insigna.ie.u-ryukyu.ac.jp> Shinji KONO (7/23)

最近、読んだ本 Writing Solid Code にもassert を多用し、出荷時には消す」みたいな話が載ってましたが、根本的に間違っているんじゃないかな。

<bfor0m$b76$1@bgsv5648.tk.mesh.ad.jp> tabe (7/24)

しかし、

・原子力発電所の制御
・航空機の制御、
・自動車エンジンの制御

等で、ａｓｓｅｒｔを有効にして出荷する事が、良い事なのか、悪い事なのか、私にはわかりません。

<m3u19bx54f.fsf@maedapc.cc.tsukuba.ac.jp> MAEDA Atusi (7/25)

無ければ，何が起こるか分からない．バグの記録も残らない．チェックが入れてあれば，少なくとも記録は(たとえばNVRAMに)とれるし，うまくすればフェイルセイフ処理を試みることもできるでしょう．

<bfpisc$d7$1@bgsv5648.tk.mesh.ad.jp> tabe (7/25)

コンパイラ提供の、assert() と、単なるデバッグプリント文を明確に分けて考えてください。assert() は、プログラムが即死します。

<m3ptjzwf2c.fsf@maedapc.cc.tsukuba.ac.jp> MAEDA Atusi (7/25)

＃むかっっ

元々SNAPという「単なるデバッグプリント」マクロの話だったのではないですか．なんで偉そうに説教されなきゃならんのか．

簡便なassertは便利な場合も多いですが，自ずと限界があります．ケースバイケースとしか言いようがないでしょう．

<3988646news.pl@insigna.ie.u-ryukyu.ac.jp> Shinji KONO (7/25)

というわけで、僕の立場は、

エラー処理をしないことが前提のassertは、製品化しないようなプログラム(あるいは、マイクロソフトの売ったら勝ち、バグは知らん方針)が前提であり、時代遅れであって、使ってはいけないものだ。

ってなもんです。

◆ [pgsql-jp] 画像データベースの作成。

[30568] キャスター　マイルド (7/24)

バイナリデータのデータベース化を計ろうと考えるとき、直接PostgreSQLに格納するか、データは別の所に保存し、その情報（ファイル名やサイズなど）のみをデータベースに放り込むか、どちらが良いでしょうか？

[30573] Tatsuo Ishii (7/24)

large objectを使った方が管理やアプリケーションの手間が減っていいのですが，単純にファイルに置く場合に比べると容量が増えてしまいます．

[30576] Tanaka-Qtaro-Yasuhiro (7/24)

このメーリングリストの以下のメールから始まるスレッドが参考になると思います。

[pgsql-jp 21110] ラージオブジェクトを使った画像管理
http://ml.postgresql.jp/pgsql-jp-old/pgsql-jp/2001May/threads.html#00167

[30577] 松嶋祥文 (7/24)

私は Large Object 派(?) ですが、ファイルで管理するのを避けるのは以下の理由です。

1. Permission 関係が面倒
2. ファイル名の重複回避の手段を考えるのが面倒
3. バックアップが DB と別管理になるのが面倒
4. 環境移行／同一環境作成の際に面倒
5. 上記のテストが面倒
6. ファイルシステム(ext2など)の特性を考えるのが面倒

[30587] Hirokazu Aoyama (7/25)

そういう不整合状態がシステムの仕様上クリティカルである場合は、[pgsql-jp 21164]で五十川さんがご指摘されていたように、アトミックな操作を行なえるよう、ファイル操作を用いずにDB内に閉じた操作がより好ましいと思います。

[30588] Jun Kitamura (7/25)

「ファイルの実体」と「データベース内のファイル格納場所情報」の整合が取れないような状態にするのは(私の観点からは)許されざるべきことであり、それを「仕様」としてしまうのは変です。ファイルのコピーと、データベースへのタプル挿入、の 2つを別々のトランザクションと捉える設計が間違っているだけだと思います。

[30592] Hirokazu Aoyama (7/25)

これは一見するとトランザクションのように見えますが、実際には、以下のような問題があります。

(1) ファイル処理を失敗した場合の「ロールバック」処理が本当にうまくいくのか？

(2) ファイルを削除してからCOMMITを行うまでの間にDBMSとクライアントとの通信が切れたりシグナルを受信したりして強制的にロールバックしてしまうケースも考えられる。この場合は、DB内にレコードは残っているが、ファイルは存在しないという形になる。