2014

---

Oracleの「FOR UPDATE OF TABLE.COLUMN」は、指定した項目を基準としてレコードの排他をかける構文だと思ってたが、

SELECTの対象が複数存在する場合にどのテーブルをロックするかを指定するもとの情報らしくて、

SELECT対象が１テーブルだけだとあまり意味がないらしい。

また、仮に複数あったとしても、「そのテーブルを（ロックする）」という意味しか持たず、

項目を指定することによる、その項目に関連する排他の意味合いはないようだ。（じゃあ書かせんなよ…FOR UPDATE OF TABLEだけ（COLUMN書く必要ない）でいいやんけ）

要するに項目Aと項目Bがあったら「FOR UPDATE OF 項目A」でも「FOR UPDATE OF 項目B」でも効果は同じ、ということらしい。



なお、前提として、ここでいう「そのテーブルを」というのは、FOR UPDATEを付けているSELECT側の条件（WHERE句等）に左右される。

つまり「テーブル全体をロックする」という意味ではなくて指定された条件に該当するレコードのみがロックされる。



まあでも確かに冷静に考えると、

指定した項目によっては「（その項目を指定したからって）だから何？」っていう気になるのもわかる。

これは、自身のプロジェクトにおいて、「FOR UPDATE OF TABLE.COLUMN」の「COLUMN」に指定される項目が、

得てしてKEY項目であることが多いことに由来するのだろう。

つまり「そのKEYのレコード全体をロックする」という意味合いとして使っている（書いている）と、

結果的には勝手に”勘違いしていた”ことになるのだが、

そもそも、もともとFOR UPDATE OF TABLE.COLUMNの".COLUMN"には、

Oracle的には、項目自体に対する排他等の意味や目的はなくて、

「そのテーブルを」の判断基準にしか使ってないんだから、

指定されたからといって、例えばフラグ的意味合いの項目だったとすると”値が1のレコードだけロックするの？”とか、

様々疑問が出てくることは確かである。

それに、KEY以外の項目を指定したとしたら（あるいはKEYなしテーブルだったとしたら）、

排他ができない無意味な構文になるかというと、それはそれで本末転倒であるし、

そういうことも考えると「よく考えればわかるだろ」と言われるとそうでもある。



結合してデータを取得する際に同じ名前の項目が一度のSELECT内で複数存在する場合に、

「どのテーブルの」項目かを区別する指定を明記しないと実行できずに怒られる仕様がある。

このFOR UPDATEの項目指定もそれとよく似ていて、その理由というか、経緯も多分同じなんだろう。

「Aテーブル.項目B」と「Cテーブル.項目B」が存在するとき、

単に「FOR UPDATE OF 項目B」とだけ書いても「どっちのだよ？」という気になるから、テーブル名から書かせるようになっている…

そんなところなんだろう。

だから「テーブルどころか項目名まで書かせている」というよりは「項目を書かせるためにテーブルまで指定させている」というほうが正しい気がする。

でも項目を書くことの意味がない（指定する項目によって排他の効果は変わらない）なら出発点がまず間違っていると思うのだ。

（これは俺の予想に過ぎないから事実がどうかは知らない…）

---

●ヘンリー・チャールズ・デヴィヴィエ（BILLY BAT 15巻） ●ロバート・キャンベル（東大教授、朝の情報番組「スッキリ！」に出演） こいつら似すぎ

---

動的にコマンド文字列を作って実行したい場合、そのまま文字列を書いて「`」で評価すると、
コマンド文字列内になる「'」がえてして邪魔になるときがある。
これを回避するために個人的にはよくevalを使う。

例えば以下のようなケースではうまい具合にコマンドが実行されない↓

for i in `seq 0 31`;do  
	cmd_wk="date +%Y/%m/%d --'""$i days ago""'";  
	echo "`$cmd_wk`"; ←ここがうまくいかない  
done  

これは
”現在日付から１日ずつさかのぼって日付をYYYY/MM/DD形式で標準出力する”
ことを実現したいのだが、実行すると

date: 認識できないオプション`--'0'です  
詳しくは `date --help' を実行して下さい.  

といわれて実行に失敗する。

これを回避するためにevalを使って

for i in `seq 0 31`;do  
	cmd_wk="date +%Y/%m/%d --'""$i days ago""'";  
	eval $cmd_wk  
done  

とするとうまくいく。

2014/10/06  
2014/10/05  
…  
2014/09/06  
2014/09/05  

↑2014/10/6に実行したのでこんな感じの標準出力になる。
実際には３２行出力される。

evalは引数に「実行したいコマンド文字列」を渡す。
そういう意味ではxargsに近いかもしれない（テクニックやコマンド原理の相似点はよく知らない）
最も単純な使い方では「eval ls」のようなものが出来るが、これは要するに「ls」と同じである。
「eval ls -las」なら「ls -las」と同じ効果を得る。

このevalは引数に渡した文字列そのものをコマンドとして実行しようとするので、
例えば「eval `date +%Y/%m/%d' '%H:%M:%S`」のようなevalコマンドは通常失敗する。
⇒これは引数部分の`date +%Y/%m/%d' '%H:%M:%S`＝"2014/10/06 10:21:44"という文字列をコマンドとみなすので
　自分の環境変数に指定された「2014/10/06」というコマンドを実行しようとするが、
　そんなコマンドはない旨のエラーが表示されることを表している。

---

 

---

---

HTMLのIMGタグのSRC属性には、通常外部の（自分自身のHTMLファイルとは別の）画像ファイルを指定するのだが、
画像のデータを示す文字列を指定することで、
外部の画像ファイルを使用せずに自身のHTMLファイル内で「画像」データを再現できる。
※ただしその分、HTMLファイルの容量自体が膨らむ。
特定の静的HTMLコンテンツがそれだけで完結していて、
外部の画像を読み込むような隙がない（配置された場所からしてネットワーク環境的に不可能な）ケースで使用する。
↑のような書き方をするとなんとなくレアケースにしか感じないが、実際、あったのである。（実体験故、詳しいことが書けない）

記述方法は以下の通りだ。

<img src="data:image/png;base64,[BASE64エンコードされた文字列]" alt="base64test">  

 

---

 

---

---

全角文字を含む値（VALUE）を持つjavaのpropertiesファイルは、使用する環境を考慮してか得てしてnative2ascii化されていることが多い。

よって、メモ帳やらサクラエディタ等の、一般的なテキストエディタで開くとこんな感じに見えてしまう↓

  
test.key=\u30d5\u30a1\u30a4\u30eb\u306e\u51fa\u529b\u306b\u5931\u6557\u3057\u307e\u3057\u305f\u3002  
#ちなみに"ファイルの出力に失敗しました"と書いてある  

当然この状態だと何書いてあるかわからんので日本語にしたいのだが、

知っているかぎりエディタ上でこれを日本語で復元して読み込んでくれるのはEclipseしかなく、

いちいちこのpropertiesファイルのために重いEclipse立ち上げるのも億劫で

手軽なnative2asciiの復元方法や、エディタがあればいいなあと思っていた。

どうもコマンドプロンプト上でnative2asciiコマンドを使うのが最も手っ取り早そうなので、

ここでその使い方を記述する。

---

---

を、見た。

 

（これを見た俺以外の人は）いきなり何言ってんだと思うかもしれないが実際に見たのだ。

 

いろんなゲームや漫画に「スライム」という存在は出てくるけども

この夢で対象になるのはドラクエのそれである↓

 

---

---

テーブルにdefault指定付きの項目を追加（alter table tabne_name add column_name column_type default default_value）すると、

”テーブル項目追加中（alter文実行中）”はそのテーブルに対するSELECTが待たされるらしい。

alterが終われば解放されてSELECTも通るようになる。



テーブルに項目を追加するわけだから、

追加される前（alter文実行中も「追加」が完了する前という意味では「追加される前」）に発行するselect文には

当然追加対象のテーブル項目を含めることはできないので、

追加項目を見ないselectと、これからテーブルに項目を追加するalterの両者は、一見すると無関係に見える。

だけどどうも影響を受けてしまうようだ。

---

---

OracleのFunctionの実行時間はSQLそのものの完了よりはフェッチの部分に大部分が含まれるように感じる。

Functionを呼び出したタイミングではその中身まで深く計算せず、

フェッチしている中で詳細な計算をしていくようなイメージのようである。



SELECT文の問い合わせの”結果”には、

①Oracleからの検索結果返却開始

②全検索結果のフェッチ完了

の２段階のフェーズがあるが、

SELECTする項目の一つ、ないしそのうちの一部として同じ並びで記述するFunctionは、

基本的には前者「①Oracleからの検索結果返却開始」までの間に全て寄っていて、

検索結果が返却される段階ではもう既に計算済みだと思っていた。

だがどうやらそうではない。

実際にはOracleから検索結果が返却されてから、「②全検索結果のフェッチ完了」までの間に

その計算を行っているようである。

「①Oracleからの検索結果返却開始」が開始した段階では、

実際に発行したSELECTの中に含まれるFunctionの計算は行われていないということなのだな。



仕事のとある案件においてプロジェクトで自作した業務Functionの修正を行った際、

修正前後のスピード比較をしたときにふと疑問が浮かび、簡単な実験をして知った。

Oracle的には常識なのかもしれないが自分用のメモ。

---

---

というわけで9/17発売「冬の太陽／The World Record」を購入した！

 

---

どれとは言わないが 気団まとめの「嫁と初めて会った時の会話」カテゴリに 俺が昔同じ趣旨の気団スレに書いたのが載っているのに偶然気付いた 当時は普通