アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
目玉の数さえ十分あれば、どんなバグも深刻ではない -- Eric Raymond
ちょっと意外ですが (スコア:2, 参考になる)
今まで無かった? ちょっとびっくり。
oracleで云うところの,FOR UPDATEでOpenして,fetch loop内側で
CURRENT OF...でUPDATEって事が出来る様になったって事かしらん。
って,調べてみたら,英語のリリースノートにそのまま載ってました・・・。
http://developer.postgresql.org/pgdocs/postgres/release-8-3.html
E.1.3.6. Queries
こいつは,プログラマにとっては嬉しい機能ではないでしょうか。
Re: (スコア:0)
「典型的Webアプリプログラマ(特にそれしか知らない奴)にとっては」
何のことか判らないかも。
典型的Webアプリでは
SELECT FOR UPDATEのようにデータを捕まえておくってことは
避けるベキとされているようなので。
表示画面でのSELECT(のためのDBセッション)と
次の更新画面でのUPDATEとを
いかに「べつべつに切り離す」か?が重要である、
とされているようなので。
でも、
大量の顧客を右から左に捌く外向きサービスなら
確かにそれが真なんだけど、
べつに全てのWebアプリがそういうものとは限らなくて、
(「限れ」と強制する権利は多分誰にも無い)
掴んでいることのデメリ
Re: (スコア:0)
本当にそう思うか?
いつロールバックするつもりなんだ?
ステートレスセッションが基本であるはずのwebシステムにおいて、
状態を維持することが目的のトランザクションがなじまないのは、
少し考えればすぐわかるだろう。
そもそも、httpみたいな本質的にステーフルになじまない構造と、
コネクション維持が可能でステーフルに馴染むクラサバを同一視してるあたりが、
理解不足ではないだろうか?
Re: (スコア:0)
多くの(全てとは言わないが)の「Webアプリ」では、
HTTPのステートレスっぷりをむき出しのまま使ってるわけじゃなく、
ラッパーでステートフルに見せてますね。
それによって、上位層から見れば差は無いことになります。
(期間数十分…数日という)タイムアウトという概念が有る点が違うだけで。
(というか大抵の通信にゃ
遥か下位の層にステートレスな層が有るはず。
それをラップしてタイムアウトつきステートフル通信に見せてる。
その層の位置が高いか低いかの違いだけ。)
現実で具体的に何をしているかというと、
クラサバでは