Судя по списку изменений, MyISAM они особо не правили, как в одном из предыдущих релизов. А 4.1.12 и сейчас продолжает периодически портить мою таблицу в MyISAM (4 млн. строк, параллельные удаления и добавления больших блоков строк, с блокировкой lock tables write).
Стабильная. В slackware-current она уже пакуется основным пакетом
вместо 4.0.x. Скорость прежняя. Только с русским языком появилась
засада. Идиоты сделали так, что клиент должен сам сообщать свою
кодировку серверу, а если не сообщит, то она по-умолчанию... догадайтесь
какая. В итоге приходится делать нестандартные телодвижения в скриптах
запуска сервера для поддержания русских кодировок в прежнем виде либо
перекомпилировать всех клиентов с жёстко вшитыми своими кодировками.
Короче, получился дебилизм в стиле russian apache. Нужно было делать
так, чтобы сервер объявлял свою кодировку, а клиент сам перекодировал
куда ему нужно по типу веб браузера.
UTF давно есть. Проблема в координации сервер-клиент.
Пример: база в cp1251. Равпространённое явление, не правда ли? Раньше
сервер слал данные в этой кодировке, и все друг друга понимали. Сейчас
он типа на лету перекодирует данные в кодировку клиента. А какая
кодировка у клиента? А нет никакой в старых версиях. Тогда по-умолчанию
сервер шлёт в utf-8 или latin1 (я уж не помню точно). В итоге -
кракозябры - что в винде, что в линукс-терминале.
Не понял, к чему ты это спросил. Сортировка в любом случае
осуществляется на сервере. Вопрос только в том, что он будет применять
в качестве collation.
Ничего не помогает. Ни repair table, ни смена типа на другой и обратно, ни дамп и залив обратно. То есть, помогает, конечно, но на время - до следующей порчи таблицы.
2 anonymous (*) (22.07.2005 13:52:41)
читать документацию, до тех пор пока не дойдет, во первый то о чем вы пишете только с 4.1.х, во вторый внимательно читать документацию...
> "Идиоты" сделали так, что кодировку по умолчанию можно указать в конфигурационном файле (или при сборке сервера).
Спец-сборка сервера - гимор. Это значит, что пакет из нерусского
дистрибутива использавать нельзя. Я, например, всегда использовал
официальную сборку mysql-standard-xxx, и всё прекрасно работало.
А указать в конфигурационном файле можно для консольного клиента mysql,
но попробуй указать кодировку для php скрипта... Он не читает .my.cnf ;)
> пока не дойдет, во первый то о чем вы пишете только с 4.1.х
А до тебя ещё не дошло, что здесь обсуждается конкретно 4.1.х ? Глянь
на тему топика. Документацию в отличие от некоторых я прочёл более чем
внимательно. Ибо нужно было ставить 4.1.12 на рабочий сервер.
Стабильная. В slackware-current она уже пакуется основным пакетом
вместо 4.0.x. Скорость прежняя. Только с русским языком появилась
засада. Идиоты сделали так, что клиент должен сам сообщать свою
кодировку серверу, а если не сообщит, то она по-умолчанию... догадайтесь
какая. В итоге приходится делать нестандартные телодвижения в скриптах
запуска сервера для поддержания русских кодировок в прежнем виде либо
перекомпилировать всех клиентов с жёстко вшитыми своими кодировками.
Короче, получился дебилизм в стиле russian apache. Нужно было делать
так, чтобы сервер объявлял свою кодировку, а клиент сам перекодировал
куда ему нужно по типу веб браузера.
Никогда такой проблемы не наблюдал. На 4.1.x перешёл ещё с альфа-версий, именно из-за utf-8. Сейчас - основная часть баз - в utf-8. Но есть несколько в 1251. Клиенты - utf-8, 1251 и koi8-r. Никаких нареканий. Сборка раньше ручная, сейчас - дефолтовая по "emerge mysql".
>Идиоты сделали так, что клиент должен сам сообщать свою кодировку серверу
Только сейчас заметил. А как ещё mysql узнает, какую кодировку хочет клиент, если она не дефолтовая в системе?? Телепатическую подсистему ему пока ещё не приделали, АФАИК :)
А я говорю про клиента. Похоже на то, что ты совершенно не понял, о
чём идёт речь. Запусти команду `show variables like 'char%'` и отметь
для себя, сколько там появилось новых параметров, и во что они
инициализированы.
> А как ещё mysql узнает, какую кодировку хочет клиент
А как он узнавал в версиях 4.0.x? ;)
Сервер обязан лишь сообщить, в какой кодировке он посылает данные.
Перекодировка - это проблема клиента. Что тут сложного для понимания.
Есть же могучий пример - связка вебсервер/браузер. Сервер шлёт страницу
и заявляет в заголовке: conten-type: bla; charset: x. Клиент транслирует
это в ту кодировку, какая требуется на месте.
А по мне - лучше когда всю работу делает сервер, он на то и срвер... а клиент должен все готовенькое получать, они правильно сдедали. Все кто выше и ниже - пи..
А идиоты сделали так: сервер ждёт от клиента его кодировку, а затем
на лету сам транслирует данные из кодировки базы в кодировку клиента.
Если чуть подумать, то сразу можно увидеть проблему... Не все кодировки
можно оттранслировать без потерь одна в другую.
В 4.0, ЕМНИП, была одна кодировка на всю систему. Индивидуальной кодировки по БД там не было.
>Перекодировка - это проблема клиента.
Здрасьте приехали.
>Есть же могучий пример - связка вебсервер/браузер.
А ещё есть не менее могучий пример языкового конфликта колхозников и студентов-негров из Патриса Лумумбы, приехавших на сельхозработы в 1975 году. И что?
И кстати, не вижу связи - веб/невеб - какая разница? Разговор о принципе
взаимодействия сервер/клиент, о протоколе работы с кодировками. Пример
вебсервера/браузера дан как рабочий и отлаженный годами вариант такого
взаимодействия. Он переносим на любой сервис, пересылающий данные
клиенту.
Оттуда возьмётся, что по-умолчанию все клиенты в latin1, если их
принудительно не собирать с опциями нужной кодировки. А чтобы дать
знать серверу о своей правильной кодировке, они должны слать
дополнительный sql-запрос в каждом новом соединении. В консольном
mysql-клиенте это можно обойти, прописав кодировку в конфиг, а для
perl/php скриптов таких конфигов нет. Отсюда гимор при переходе на эту
версию mysql.
Раньше было так: клиент хавал данные сервера, и никто никого не
спрашивал, что там за кодировка. Для русского хостинга базы создавались
в cp1251, и клиенты выводили инфу в этой кодировке. Подразумевалось,
что и страницы выдавались в cp1251. То есть, всё работало по-умолчанию
без ковыряния конфигов. Понятно, что такая схема сильно ограничена, но
она _работала_ и не создавала гимор. Для расширения функциональности
нужно было научить клинтов делать перекодировку в нужный для приложения
чарсет. Это было бы лучше по очень многим причинам.
Но mysql-разработчики сделали это через ж..., то есть через сервер.
Ещё раз объясняю. [client] читается только прогами, которые идут в
составе mysql сервера - mysqladmin, mysqldump, консольный клиент mysql
и т.д. PHP его не читает! Да и что тут странного? Он ведь используется
разными клиентами!
Правильно. Кодировка БД устанавливалась одна на всю систему. И клиенты
и сервер работали в одной и той же кодировке. То есть, она была
умолчальная для всех. Ты спрашивал, как сервер узнает кодировку клиента.
Как видишь, ранее как-то справлялись.
> >Перекодировка - это проблема клиента.
> Здрасьте приехали.
Куда приехали и что непонятно с этим пунктом?
> А ещё есть не менее могучий пример языкового конфликта колхозников и студентов-негров
Один хрен ни те, ни другие русского языка не знали, но тем не менее,
общались всё-таки на одном языке ;)
> А голова программисту дана не только для того, чтобы красные глаза к ней прикреплять.
Да ну что за хрень ты несёшь? При чём тут вообще программист? Вот жил
сайт много лет, и на нём много лет крутились сотни скриптов. Обновили
mysql до версии 4.1.12, и всё, весь сайт в кракозябрах. Хотя ничего не
менялось. Я знаю, как это поправить глобально, но в любом случае -
решение с трансляцией чарсетов на сервере - кривое.