MySQL 4.1.13

а это стабильная версия?
и как оно по сравнению с тройкой - новые фичи на скорости не сказались?

>> Вышла новая стабильная версия СУБД MySQL
> а это стабильная версия?

=)

Судя по списку изменений, MyISAM они особо не правили, как в одном из предыдущих релизов. А 4.1.12 и сейчас продолжает периодически портить мою таблицу в MyISAM (4 млн. строк, параллельные удаления и добавления больших блоков строк, с блокировкой lock tables write).

Главное - это новость о 13-й версии в пятницу напечатать :D

Стабильная. В slackware-current она уже пакуется основным пакетом
вместо 4.0.x. Скорость прежняя. Только с русским языком появилась
засада. Идиоты сделали так, что клиент должен сам сообщать свою
кодировку серверу, а если не сообщит, то она по-умолчанию... догадайтесь
какая. В итоге приходится делать нестандартные телодвижения в скриптах
запуска сервера для поддержания русских кодировок в прежнем виде либо
перекомпилировать всех клиентов с жёстко вшитыми своими кодировками.

Короче, получился дебилизм в стиле russian apache. Нужно было делать
так, чтобы сервер объявлял свою кодировку, а клиент сам перекодировал
куда ему нужно по типу веб браузера.

это что, в mysql ещё utf-а нету???

сначала думай - потом пиши.

клиент сам сортировкой должен заниматься?

> Идиоты сделали так, что клиент должен сам сообщать свою кодировку серверу, а если не сообщит, то она по-умолчанию... догадайтесь какая.

"Идиоты" сделали так, что кодировку по умолчанию можно указать в конфигурационном файле (или при сборке сервера).

UTF давно есть. Проблема в координации сервер-клиент.

Пример: база в cp1251. Равпространённое явление, не правда ли? Раньше
сервер слал данные в этой кодировке, и все друг друга понимали. Сейчас
он типа на лету перекодирует данные в кодировку клиента. А какая
кодировка у клиента? А нет никакой в старых версиях. Тогда по-умолчанию
сервер шлёт в utf-8 или latin1 (я уж не помню точно). В итоге -
кракозябры - что в винде, что в линукс-терминале.

2 Sorcerer
небось после апгрейта с 3.х версий? сделай дамп и задей обратно

> клиент сам сортировкой должен заниматься?

Не понял, к чему ты это спросил. Сортировка в любом случае
осуществляется на сервере. Вопрос только в том, что он будет применять
в качестве collation.

> небось после апгрейта с 3.х версий?

Нет.

> сделай дамп и задей обратно

Ничего не помогает. Ни repair table, ни смена типа на другой и обратно, ни дамп и залив обратно. То есть, помогает, конечно, но на время - до следующей порчи таблицы.

2 anonymous (*) (22.07.2005 13:52:41)
читать документацию, до тех пор пока не дойдет, во первый то о чем вы пишете только с 4.1.х, во вторый внимательно читать документацию...

2 Sorcerer
версия mysql? бинари какие(чья сборка, компилятор...)?

> "Идиоты" сделали так, что кодировку по умолчанию можно указать в конфигурационном файле (или при сборке сервера).

Спец-сборка сервера - гимор. Это значит, что пакет из нерусского
дистрибутива использавать нельзя. Я, например, всегда использовал
официальную сборку mysql-standard-xxx, и всё прекрасно работало.

А указать в конфигурационном файле можно для консольного клиента mysql,
но попробуй указать кодировку для php скрипта... Он не читает .my.cnf ;)

> версия mysql?

4.1.12. На предыдущих 4.1.* было то же самое.

> бинари какие(чья сборка, компилятор...)?

gcc 3.4.2, статическая линковка, с оптимизированными флагами, из портов FreeBSD. Я как-то собирал его даже icc - та же ошибка оставалась.

> пока не дойдет, во первый то о чем вы пишете только с 4.1.х

А до тебя ещё не дошло, что здесь обсуждается конкретно 4.1.х ? Глянь
на тему топика. Документацию в отличие от некоторых я прочёл более чем
внимательно. Ибо нужно было ставить 4.1.12 на рабочий сервер.

> На предыдущих 4.1.* было то же самое.

А до того? База ведь наверняка когда-то крутилась на 4.0.x.

2 Sorcerer
для bsd ничего подсказать не могу, могу только сказать, что может быть дело в файловой системе и при больших нагрузках рекомендую InnoDB

Я бы не рускнул ставить важную mysql базу на FreeBSD. Уж больно оно
криво. Да и тормозно.

Уж лучше тогда на венду. Всяко лучше.

> А указать в конфигурационном файле можно для консольного клиента mysql, но попробуй указать кодировку для php скрипта... Он не читает .my.cnf ;)

Я говорю про сервер. Доки: http://dev.mysql.com/doc/mysql/en/charset-server.html

Стабильная. В slackware-current она уже пакуется основным пакетом вместо 4.0.x. Скорость прежняя. Только с русским языком появилась засада. Идиоты сделали так, что клиент должен сам сообщать свою кодировку серверу, а если не сообщит, то она по-умолчанию... догадайтесь какая. В итоге приходится делать нестандартные телодвижения в скриптах запуска сервера для поддержания русских кодировок в прежнем виде либо перекомпилировать всех клиентов с жёстко вшитыми своими кодировками.

Короче, получился дебилизм в стиле russian apache. Нужно было делать так, чтобы сервер объявлял свою кодировку, а клиент сам перекодировал куда ему нужно по типу веб браузера.

Анонимус, вы дебил.. А они сделали правильно

Да нормально... вполне, и безо всяких тормозов...

> А до того? База ведь наверняка когда-то крутилась на 4.0.x.

Нет, я сразу на 4.1 ставил, даже еще когда эта ветка не была стабильной.

2 anonymous (*) (22.07.2005 14:20:41) не батенька это вы дебил, потому что фишки с charset появились в 4.1.x а не в 4.0.x и об этом написанно здесь http://dev.mysql.com/doc/mysql/ru/todo-mysql-4-1.html

если вы дечтка и на русском не сможет это узреть, то вам может тогда професию сменить

> Главное - это новость о 13-й версии в пятницу напечатать :D

на сайте MySQL 4.1.13 был доступен для закачки в четверг с утра

>Проблема в координации сервер-клиент.

Никогда такой проблемы не наблюдал. На 4.1.x перешёл ещё с альфа-версий, именно из-за utf-8. Сейчас - основная часть баз - в utf-8. Но есть несколько в 1251. Клиенты - utf-8, 1251 и koi8-r. Никаких нареканий. Сборка раньше ручная, сейчас - дефолтовая по "emerge mysql".

>на сайте MySQL 4.1.13 был доступен для закачки в четверг с утра

Так я ж и пишу не про время выхода (он 15-го вышел, кажется), а про время новости. Учитесь читать :)

>Идиоты сделали так, что клиент должен сам сообщать свою кодировку серверу

Только сейчас заметил. А как ещё mysql узнает, какую кодировку хочет клиент, если она не дефолтовая в системе?? Телепатическую подсистему ему пока ещё не приделали, АФАИК :)

> Я говорю про сервер. Доки: http://dev.mysql.com/doc/mysql/en/charset-server.html

А я говорю про клиента. Похоже на то, что ты совершенно не понял, о
чём идёт речь. Запусти команду `show variables like 'char%'` и отметь
для себя, сколько там появилось новых параметров, и во что они
инициализированы.

> Анонимус, вы дебил.. А они сделали правильно

Про них я уже сказал, а про тебя думаю точно так же.

> А как ещё mysql узнает, какую кодировку хочет клиент

А как он узнавал в версиях 4.0.x? ;)

Сервер обязан лишь сообщить, в какой кодировке он посылает данные.
Перекодировка - это проблема клиента. Что тут сложного для понимания.
Есть же могучий пример - связка вебсервер/браузер. Сервер шлёт страницу
и заявляет в заголовке: conten-type: bla; charset: x. Клиент транслирует
это в ту кодировку, какая требуется на месте.

быдловебопрограммер убей себя. субд не только с браузером работают.

А по мне - лучше когда всю работу делает сервер, он на то и срвер... а клиент должен все готовенькое получать, они правильно сдедали. Все кто выше и ниже - пи..

А идиоты сделали так: сервер ждёт от клиента его кодировку, а затем
на лету сам транслирует данные из кодировки базы в кодировку клиента.
Если чуть подумать, то сразу можно увидеть проблему... Не все кодировки
можно оттранслировать без потерь одна в другую.

Для быдлоневебпрограммера по секрету сообщу: конкретно mysql на 99%
используется именно в веб проектах.

> а клиент должен все готовенькое получать

Ну вот он получит трансляцию из cp1251 в latin1. И будет кушать
готовенькое на букву "г" ;)

>А как он узнавал в версиях 4.0.x? ;)

В 4.0, ЕМНИП, была одна кодировка на всю систему. Индивидуальной кодировки по БД там не было.

>Перекодировка - это проблема клиента.

Здрасьте приехали.

>Есть же могучий пример - связка вебсервер/браузер.

А ещё есть не менее могучий пример языкового конфликта колхозников и студентов-негров из Патриса Лумумбы, приехавших на сельхозработы в 1975 году. И что?

>Не все кодировки можно оттранслировать без потерь одна в другую.

А голова программисту дана не только для того, чтобы красные глаза к ней прикреплять. "Машина должна работать. Человек - думать".

>Ну вот он получит трансляцию из cp1251 в latin1.

А откуда там latin1 возьмётся? От кривых рук программмера или админа? Тогда всё может быть.

И кстати, не вижу связи - веб/невеб - какая разница? Разговор о принципе
взаимодействия сервер/клиент, о протоколе работы с кодировками. Пример
вебсервера/браузера дан как рабочий и отлаженный годами вариант такого
взаимодействия. Он переносим на любой сервис, пересылающий данные
клиенту.

Оттуда возьмётся, что по-умолчанию все клиенты в latin1, если их
принудительно не собирать с опциями нужной кодировки. А чтобы дать
знать серверу о своей правильной кодировке, они должны слать
дополнительный sql-запрос в каждом новом соединении. В консольном
mysql-клиенте это можно обойти, прописав кодировку в конфиг, а для
perl/php скриптов таких конфигов нет. Отсюда гимор при переходе на эту
версию mysql.

Раньше было так: клиент хавал данные сервера, и никто никого не
спрашивал, что там за кодировка. Для русского хостинга базы создавались
в cp1251, и клиенты выводили инфу в этой кодировке. Подразумевалось,
что и страницы выдавались в cp1251. То есть, всё работало по-умолчанию
без ковыряния конфигов. Понятно, что такая схема сильно ограничена, но
она _работала_ и не создавала гимор. Для расширения функциональности
нужно было научить клинтов делать перекодировку в нужный для приложения
чарсет. Это было бы лучше по очень многим причинам.
Но mysql-разработчики сделали это через ж..., то есть через сервер.

а в [client] разве нельзя прописать encoding ?

Ещё раз объясняю. [client] читается только прогами, которые идут в
составе mysql сервера - mysqladmin, mysqldump, консольный клиент mysql
и т.д. PHP его не читает! Да и что тут странного? Он ведь используется
разными клиентами!

> не батенька это вы дебил, потому что фишки с charset появились в 4.1.x а не в 4.0.x

Чудик, здесь обсуждается ______только_______ поведение mysql-4.1.x.
Таких дебилов я ещё не видел. Вроде понятно было сказано. Откуда ты
приплёл 4.0.x?

> Индивидуальной кодировки по БД там не было.

Правильно. Кодировка БД устанавливалась одна на всю систему. И клиенты
и сервер работали в одной и той же кодировке. То есть, она была
умолчальная для всех. Ты спрашивал, как сервер узнает кодировку клиента.
Как видишь, ранее как-то справлялись.

> >Перекодировка - это проблема клиента.
> Здрасьте приехали.

Куда приехали и что непонятно с этим пунктом?

> А ещё есть не менее могучий пример языкового конфликта колхозников и студентов-негров

Один хрен ни те, ни другие русского языка не знали, но тем не менее,
общались всё-таки на одном языке ;)

> А голова программисту дана не только для того, чтобы красные глаза к ней прикреплять.

Да ну что за хрень ты несёшь? При чём тут вообще программист? Вот жил
сайт много лет, и на нём много лет крутились сотни скриптов. Обновили
mysql до версии 4.1.12, и всё, весь сайт в кракозябрах. Хотя ничего не
менялось. Я знаю, как это поправить глобально, но в любом случае -
решение с трансляцией чарсетов на сервере - кривое.

>но попробуй указать кодировку для php скрипта... Он не читает .my.cnf ;)

mysql_query('set character set koi8r');