先日、gusagiさんより、bulletinHDについてのバグレポートとして、以下のURLを転送してもらいました。
http://ryus.co.jp/modules/d3blog/details.php?bid=107
先に結論から書くと、このエントリはMySQLの基本的なcase sensitiveルールを誤解していることによる、間違ったレポートです。
Quote:
この現象は、 Windows環境で作成したDBのデータをUNIX環境に持って行った場合に限定されます。
この時点でバグでも何でもありません。まずはこっちを読んでください。
http://dev.mysql.com/doc/refman/4.1/ja/name-case-sensitivity.htmlQuote:
ただ、WARPなどの環境でデータを作成してから、UNIX環境にデータを移行して運用なんてケースも考えられるので、その場合は上記パッチを適用して頂いた方が良いと思われます。
そういう「仕様外」のことをやりたければ、lower_case_table_names=1 を使うべきでしょうし、もしなんらかの理由でソースコードを改変するしかない場合でも、Database::prefix()の方にかければ一箇所で済みます。SQL生成部すべてにstrtolower()をかける、という方法はメンテナンス性という観点からも筋が悪すぎます。
# 個人的には、Case sensitiveな環境がターゲットなのに、Case insensitive環境で開発しているっていうのがあり得ない…
ただ、このレポートのおかげで私も一つ勘違いしていたことに気付きました。
それは、caseしか違わないdirnameで、2つのモジュールが同時には動かせない、ということです。
当たり前ですが、case sensivie環境で動かすのなら、XOOPSにおけるdirnameも原則的にcase sensitiveです。例えば、XUGJのQandAフォーラムは、あくまで"QandA"であり"qanda"ではありません。(中身はd3forum)
http://www.xugj.org/modules/QandA/上のリンクは生きてますが、
http://www.xugj.org/modules/qanda/下のリンクは死んでます。
「つまり、D3モジュールでありさえすれば、picoがインストールされている環境でも、PICOというdirnameで別のモジュールとしてインストールできるだろう」
ここに思い込みがありました。
実際にはcase sensitiveな環境でもインストールできません。
なぜならSQLとして以下のクエリで判断されるからです。
SELECT (snip) WHERE dirname='PICO'
この 'PICO' はcase insensitiveに比較され、'pico'と一致します。
つまり、インストール済だよ、というメッセージで拒否されます。当たり前ですが、インストーラだけを無理矢理通過させても意味がありません。やはり同様のクエリによって、モジュールの分岐処理がなされるからです。
では、どうすれば良いのか。答えは簡単です。
ALTER TABLE (prefix)_modules MODIFY `dirname` varchar(25) binary NOT NULL default '';
としてあげれば良いのです。dirnameカラムにbinary属性を加えることによって、case sensitiveになりました。
これを実際に試してみると、picoとPICOが普通に共存できました。
まあ、そんな需要もほとんどないとは思いますが、ちょっとしたTipsくらいに覚えておくと、今後役に立つことがあるかもしれません。
なおこの場合、言語定数オーバーライド機能の一部が、picoとPICOでは独立して働きません。
それは、
$constpref = '_MI_' . strtoupper( $mydirname ) ;
というコードによるものです。
考えてみたら、定数名が大文字である必然性などどこにもなく、strtoupper() を$dirnameにかけることは、バグ以外の何物でもないでしょう。
今後のD3モジュールでは、$constprefへのstrtoupper()を外していきます。(各種言語ファイルに含まれてしまっているのがかなり面倒だったりしますが…)