日々の破片

_ TableAdapterでエラーなりまくり

あああ、型付き言語ってこういうことか、と何度頭をかきむしったことか(大げさだけど）。

Railsの場合、migrateしてカラムを変えたりしながら、ちゃかちゃかやっていく。としても、あまりモデルをいじらなくても済む（validateとか、自分で書いたところは直す必要はある）。ここで重要なのは、直す必要があるのは自分で書いたところということ。

ADO.NETでは、何もしなければ単に例外を食らう。

何を食らいまくったかといえば、制約違反例外。

でも、制約違反ってなぜ？

と、たとえば、さっきまでchar(6)だったカラムをchar(8)に変えて、当然のように変えたなりのデータが入っているのだが、それを読むと制約違反例外。さっぱり理解できなかったわけだ。

で、どうも再生成するとどうしたとか、@itの掲示板がGoogleで引っかかって、理解した。で、ジェネレートしたソースを見ると、桁数が確かに埋め込まれているわけで、ああ、しょうがないな、とXSDを開いて再ジェネレート。

その後も、一昨日あたりに作ったジェネレーションギャップを埋めるためのメソッド回りでエラーになったり。

クェリーを利用するとLIKE演算子が使えなくて、（無理やり書いたらどうも正しく条件節が生成されていないらしい動きになる。）。で、しょうがないからギャップを埋めるほうにSQLを書いて（ADO.NET自体はfoo LIKE @param1 を受付可能。あくまでも生成したTableRowの実装の問題で、うまくいかないみたい。早い話がLIKEと書いているのに＝として解釈されているようだ。SqlParameterクラスの生成方法に原因がありそうだが、時間がないのでCommandSetに独自に作ったText（＝SQL)を設定して逃げ。で、逃げついでに読み取るカラムを元のからいじって、エラーになるからParameterとかもいじって……とかやったら、NOT NULL制約のカラム（読まないように変えた）にどうも代入しようとしてそれがDbNullなもんで例外を食らうとか。

いや、とても楽しめた。ADO.NETはうまくできていることは事実。だからそこまでしてTableAdapterを使うのだが、（TableRowを生成してくれるのが大きいんだが、それが逆に面倒の元なのも事実）、数時間おきにレイアウトが変わるテーブルへの利用はあまり向かないという予想を裏付けるだけの結果となってしまった。まったくActiveRecordはちょろい（ただしパフォーマンスコンシャスなんで、仮にActiveRecordが使えたとしてそれが本当に有効かは別問題。いずれにしろADO.NETを使うと決めたわけだし、他でもないおれが）。

事実なんだが、ActiveRecordに比べるとかったるいのもまた事実。

_ アマゾン時間

3Dドラゴン届いたとか。

あの時点では11月のはずだったのに、一転（ヒューマンコミュニケーション重要なアマゾン……ITなんてそんなもんだよ）。もちろん、僕のところへは予定通りまだ届いていない。

#というか、DELLはどうなってるんだろうか。まったく音沙汰が無いんだけど。

_ スルー力カンファレンス

またおもしろそうなカンファレンスが。早速事前登録。