村上です。

At Tue, 29 Jun 2004 18:27:07 +0900 (JST),
Hirofumi Fujiwara wrote:
> 
> 藤原です。

>   実際に、テーブルを作ってテストしてみました。
> 
>   ALTERしても、以前から入っているデータはそのまま長くても入ったままで
>   した。
>   新たに入れたり変更しようとした場合にだけ、新しく解釈された長さで切ら
>   れますね。

そうなんです。
見た瞬間に「んん？」と思ってしまいます。

逆に 4.1 で char(255) で作ったテーブルを、4.0, 3.23 でアクセスさせると
これまた「え！？」な状態です。

> > >   1. で確認して、必要なら ALTERするので通常は充分と思います。
> > > 
> > >   たくさんテーブルができている場合もあるだろうから、指定したデータベー
> > >   スの全テーブル（または指定のテーブル）について、確認する手段の提供が
> > >   欲しいです。
> > 
> > SHOW TABLE STATUS; で出てくれればうれしいかな。
> > 
> > SQL で確認できれば、変換スクリプトも簡単に用意できそう。
> 
>   古いバージョンは、バイト単位で、新しいのが文字単位になっています。安
>   全を期せば、8 と書かれていたものは、新しい方でも 8 にすることでしょ
>   う。
> 
>   しかし、そうすると無駄も多くなるし、レコードの長さが長くなり過ぎて、
>   そちらの制限に引っ掛かってしまう場合も発生しかねませんね。
> 
>   できるだけ効率よく作ろうとすると、実際に入る文字数に合わせるべきでしょ
>   うから、自動は難しいのではないでしょうか。

サーバーが自動で変換することは、私は考えていません。
DB 管理者が、手動で変換する方がいいと考えています。
単純に shell でも Ruby でも、スクリプトを書けばいいと。

そのスクリプトの例が ML にでも MyNA の web などにでもあれば、
スクリプトが無いとあるとじゃ大違い、と考えています
スクリプトは簡単なものでいいと考えています。存在することが大事。

スクリプトでの判定方法ですが、

SHOW TABLE STATUS; 
に、ver という項目を付けて、そこに frm のバージョン番号を出すように
開発者側に投げておきました。
返ってくる数値や項目名はどうなるかは未定ですが、
SHOW TABLE STATUS; 
.... |ver|
.....|  7|
の結果を見ればいいということです。


スクリプトでの処理は、
SHOW TABLE STATUS
SHOW CREATE TABLE
ALTER TABLE
する。
ALTER の時の char(m) の長さの計算は、
ujis の時は、m = (n + 1) * 3
sjis の時は、m = (n + 1) * 2
ただし
 n は 4.1 で表示されたchar() の値で、これは 4.1 未満のテーブルの状態
 m は 変換後の値
 m は最大で 255
とすればいいと思っています。

微調整は、DB 設計者が行う、と。


Warning を出す件ですが、
Warning は、私の方からは、全てのクエリ実行時に出して欲しいという
話を投げましたが、
開発側は、全てには Warning を出したくないらしくて
Warning は限定されたクエリでしか出ないようになる雰囲気です。
# そりゃ、1バイトしか使っていない人にはうっとおしいのはわかるが、
# 仕様が大きく違うので出した方がいいぞ


================
村上 takeshi@xxxxxxxxxx