論理削除フラグに一言

PG

どういう実装になるのか気になったので書いてみる。

何が気になったかって一意制約。こういうデーターは「PKになるだろう」って説もあるが、昨今のフレームワークの作法で祖も行かないことも多い。さて本題。


物理削除(ログテーブルに移してからの)の場合、再度同じのデータをinsertしてもすでに削除されているので、一意制約に違反することはないけど、論理削除(フラグによる論理削除)の場合、思いっきり違反しますよね。

これをどうやって実装してるのか非常に気になります。


ちょっと考えてみた。

論理削除と合わせて一意制約

でも、再度登録されたデータを削除すると、ここで一意制約違反。

なので、削除フラグが0/1な値にならなくなる。削除時に値を取得して、その値に更新。値はPKのhashとか、削除フラグ用にシーケンスを用意するとかでいいだろう。


・・・筋悪な気がしてならない。

アプリからレコードを削除するのにどれだけコードを書くんだよ。

そもそもどれだけのレコードが削除される? 該当列につけるであろうindexの効果は?


制約は設けずに、アプリでチェック

一度selectしてデータの一意性を確認してからinsertすれば一意になる。

だけど同時更新があると駄目。
二つのトランザクション(A,B)があったとして、同時に同一のデータをinsertしようとする

  1. Aでselect。同一データなし
  2. Bでselect。同一データなし
  3. Aでinsert
  4. Bでinsert

ってなったときに同じ値ができてしまう。
select前にテーブルロックすれば回避できるがそれでいいの？


きっと、こういった問題のないエレガントな方法があるんだろうなー。

交換法則のない世界

数学

http://blogs.itmedia.co.jp/magic/2011/12/6886-2d5b.html
より。


6×8 は 8×6 とは違うのか。

よく考えたら、交換法則の存在しない世界での数式なら×だわ。文章と違う計算やってるんだから答えがあっててもそれは偶然の一致でしか無いんだから、理解を評価するテストなんだから×にすべき。*1


この問題は、数と単位の関係を正しく読み取れているかを聞いているんでしょう。
だから、8人に6本と、6人に8本は違うんだから×でしょ。算数のルールとして掛けられる数は左ってなってるんだし、被乗数と乗数を入れ替えても結果が変わらないルール(交換法則)もないんだし。


ところで、ここ来るまでに、演算と単位の関連性について教えてるんですかね？

  • 加減は同じ単位(概念)のものでしかできない。
  • 乗除は異なる単位(概念)のものの間で行う。

簡単な話だけど、重要なこと。


オチとしては、算数の授業も受験数学と同様に、出題者が望む解答+解法を示すテクニックを習うものである。ということでいいんじゃないかな？


追記
問題の本質は、

  1. 問題文から乗数、被乗数にふさわしい数を抜き出し(被乗数)×(乗数)の形で記述せよ。
  2. （１）で立てた式を計算せよ。

なのでしょう。
とは言っても、「以下の問題文から乗数、被乗数にふさわしい数を抜き出し(被乗数)×(乗数)の形で記述せよ。」なんてメタな出題ができないわけで。

*1:この偶然の一致は偶然ではなく、そこを追求することに大きな価値があることは確実

ログインさせたくないけどshellはほしい

linux

あんまりないケースかもしれないけど、ないわけじゃないので。


通常ログインさせたくないユーザー(デーモンのユーザーなど)は/sbin/nologinなんかをログインシェルにして、ログインできないようにするが、これだとシェルそのものが起動しない。

何をやりたかったかというと、apacheでatdを使いたかった。

  1. リクエストを受けて、ジョブをキック
  2. レスポンスでジョブの進捗表示画面を
  3. ajaxでリアルタイムに更新し、状況を見えるようにする

ってことをするので、apacheでatジョブを登録するんだけど、atdって、実行ユーザーのシェルを起動して、そいつにコマンドを渡すようでジョブをキックできなかったんですね。

で、回避策としてやったのが、

  1. ログインシェルをbashに
  2. .bash_profile に exit
  3. .bashrc に exit

で一応できた。

セキュリティー的に同なのか気になるところ。apacheでシェルを起動できないのは確かめたんだけどね。

リリース時の注意

cakePHP

cakePHPを使っての開発。色々と使えそうなものが一揃えあってさくさく進む。

さて、修正や機能追加の案件で一通り造り終えて、いざ本番にリリースしたら動かねー！！なんてことに直面した。


とりあえず手元の開発環境で状況を確認してもちゃんと動いてる。頭を抱えていたところだったが、ひとつ思い当たることが。

キャッシュでした。モデルの。

cakePHPってテーブルの構造をapp/tmp/cache/model以下にファイルとして残しておくんですね。デバックレベルが開発だと、このキャッシュは都度更新されるんだけど、本番だとしなくなる。

スキーマの修正を伴う改修を行った場合、こいつを削除してあげる必要がある

あせった、あせった。