アカウント名:
パスワード:
なんとなく動かす系のやり方しか無いのでは？
これは逆です。
4.0までがマトモではなかったのです。 4.1から文字列を文字列として扱うようになりました。
ハマっている人たちは、4.0までの適当さに頼った使い方をしていて、そのツケがまわってきただけです。
そもそも、現段階では日本語の正規表現/全文検索も出来ない訳ですし
できます。
大量のテキストに対して現実的な速度を求めるなら、Rast, Senna, HyperEstraierあたりを使いましょう。
まだencoding周りちゃんとした実装されてないでしょ？
されていますよ。いつの時代の話ですか?
内部仕様変わったのが原因なのに、
『今までコンパイル通ってたのに、コンパイラのバージョンあげたら通らなくなった! どうしてくれる!』ってくらい的外れ。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
「毎々お世話になっております。仕様書を頂きたく。」「拝承」 -- ある会社の日常
そんなことより (スコア:1, 興味深い)
やれ default-character-set を binary で使え、とか
skip-character-set-client-handshake でとりあえず大丈夫、とか
その他色々ありましたけど、現段階においても上に挙げたような、
なんとなく動かす系のやり方しか無いのでは？
結局の所、何処かの Web アプリよろしく 4.0.27 辺りを使い続けるか、
PostgreSQL 辺りに乗り換えるかしかないのが現状で、使う利点や、使うべきでない理由なんてものは、
それらが解決した後に初めて生きてくる話ですね
そもそも、現段階では日本語の正規表現/全文検索も出来ない訳ですし
立ち位置からしてもそれほど違う MySQL を、本家/. と一緒のつもりで議論してもしょうがないでしょう
# ええ、私もやりましたよ、4.0 → 4.1over の為の ujis → utf8 変換、半泣きになりながらね
# 変換で化けたデータをシコシコ手直しもしました
# その後は、サーバー/クライアント間の文字コードの同期ですよ
# SHOW VARIABLES LIKE 'char%'; の出力を眺めながら気が狂いそうでした
# なんでバージョンが 0.1 上がった程度でここまでハマりますかね
# まあ社内で MySQL を使おう、と言い出したのは私ですしね、責任は取らされ^H^H^Hりました
Re:そんなことより (スコア:4, 参考になる)
これは逆です。
4.0までがマトモではなかったのです。 4.1から文字列を文字列として扱うようになりました。
ハマっている人たちは、4.0までの適当さに頼った使い方をしていて、そのツケがまわってきただけです。
できます。
大量のテキストに対して現実的な速度を求めるなら、Rast, Senna, HyperEstraierあたりを使いましょう。
Re:そんなことより (スコア:3, 参考になる)
Re:そんなことより (スコア:0)
3月下旬にmysqlのjpなMLで流れた話題ですね。
＃いつ修正されるんだろう
というか (スコア:0)
＃少し前のＭＬにもそんな内容がPOSTされてたはず
＃修正されましたの内容も
そういう意味では、また使う気には、個人的になれない
>ハマっている人たちは、4.0までの適当さに頼った使い方をしていて、
>そのツケがまわってきただけです。
内部仕様変わったのが原因なのに、なんでそんな発言になるのか
理解不能
Re:というか (スコア:1)
されていますよ。いつの時代の話ですか?
『今までコンパイル通ってたのに、コンパイラのバージョンあげたら通らなくなった! どうしてくれる!』ってくらい的外れ。
Re:というか (スコア:0)
DB形式に影響でる仕様変更って時点で十分マズイ気もするが。
まぁ、DBは運用始まった時点でバグFIX以外で
バージョン変えない方がええんだけどね。
Re:というか (スコア:0)
Re:というか (スコア:0)
適当さに頼った使い方をしていたんだと思うのだけれど。
Re:というか (スコア:0)
によれば 修正されるのは5.1以降でしょうといわれていたのですが
5.0系で修正されたのですか？
＃これをふまえていってるんですがね
Re:というか (スコア:0)
Re:そんなことより (スコア:0)
設定面でもその後の使用面でもハマるようなことはなかったなぁ。
４⇒５の乗換えで大変苦労したのでAC