Представлен (http://permalink.gmane.org/gmane.comp.db.mysql.announce/479) MySQL 6.0.11 (http://www.mysql.com/mysql60/), последний релиз в ветке 6.0.x, находящейся на стадии альфа-тестировании и включающей в себя два новых движка - Falcon (http://www.mysql.com/why-mysql/white-papers/falcon-getting-s...) и Maria (http://dev.mysql.com/doc/refman/6.0/en/se-maria.html). Среди новшеств версии 6.0.11 можно отметить добавление поддержки конструкций SIGNAL и RESIGNAL, определенных в SQL стандарте; включение в комплект новой утилиты mysqlbackup, отображающую информацию из резервных копий, созданных при помощи операции "BACKUP DATABASE" statement.
После выпуска данной версии MySQL Server переходит на
новую модель (http://forge.mysql.com/wiki/Development_Cycle) подготовки релизов в рамках которой будет развиваться единая тестовая ветка MySQL Trunk с более частым выпуском тестовых версий. Ранее практиковавшийся подход, когда в разработке нередко находилось одновременно несколько тес...URL: http://permalink.gmane.org/gmane.comp.db.mysql.announce/479
Новость: https://www.opennet.ru/opennews/art.shtml?num=21859
Кто знает, в MySQL уже починили вопросики?
что вы имеете ввиду?
Почини себе руки и поставь нормальную кодировку на базу/коннект/сервер.
SET NAMES UTF8/CP1251/....(ненужное убрать) не пробовал?
База UTF8, set names в кодировку исходного текста делал. при селекте данных вопросики. ЧЯДНТ? Тот же скрипт переделан на постгрес (заменены функции mysql_* на pgsql_*) - всё отлично.
осталось открыть секред - какая CMS?
set names делать надо не в "исходную", а в ту кодировку, в которой хочешь получать ответы.
>set names делать надо не в "исходную", а в ту кодировку, в
>которой хочешь получать ответы.Ответы на что, на INSERT INTO ... ?
Ниже писал уже: исходные данные в csv (экспорт из епселя), кодировка 1251, это парсится и пихается в базу. База UTF8, таблицы каждая в отдельности тоже UTF8 (приятный гемор, чОткий ход разработчиков, в этом месте было уже весело), скрипт-парсер выставляет set names в 1251, при селекте - вопросы. Повторяю, проблема с перекодировками, она у них генетическая, похоже. Выставлять кодировку на всю СУБД (о ужас) не предлагать, случай как раз из серии тех, когда это не подходит.
Почему такого геморроя нет в постгресе? И не надо брызгать слюной, как один молодой и неокрепший выше, я _хочу_ использовать mysql, поскольку наши девелоперы (которым в дальнейшем сопровождать) с ним хоть немного но знакомы, но эти особенности не могут мне позволить этого сделать.
>Ответы на что, на INSERT INTO ... ?Ответы на селекты. Если база utf8, скрипт вставки выставил set names cp1251 и передает данные в cp1251 - то в базу всё попадает правильно (т. е. конвертится в ту кодировку, в которой таблицы - utf8 в данном случае). Скрипт который делает селекты должен выставить set names в ту кодировку, в которой хочет данные получать.
>Почему такого геморроя нет в постгресе? И не надо брызгать слюной, как
>один молодой и неокрепший выше, я _хочу_ использовать mysql, поскольку наши
>девелоперы (которым в дальнейшем сопровождать) с ним хоть немного но знакомы,
>но эти особенности не могут мне позволить этого сделать.Это не геморрой, просто один раз достаточно понять, как в mysql построена работа с кодировками. На самом-то деле проблема гроша выеденного не стоит. Единственный реальный косяк с их стороны был в миграции с 4.0 на старшие ветки, но это уже в далеком прошлом. Ну и может недостаточно хорошо в мануале все написали.
И кстати возможность контролировать кодировку вплоть до столбцов в одной таблице в некоторых ситуациях очень и очень выручает.
>Повторяю, проблема с перекодировками, она у них генетическая, похожеПроблема в ДНК тут скорее у того, кто не осилил чтение документации, а вместо себя винит разработчиков. Почему-то у тех, кто затратил хоть немного времени на беглый просмотр доки по этому вопросу, проблем с кодировками в мускуле не возникает. Причем в куда более экзотических случаях. Также не стоит ругаться на фичи, если их не понимаешь. Не нужны тебе, так не используй, никто за уши не тянет. А вот мне приходилось работать с базой, где поля в пределах одной таблицы имели разную кодировку. И представь себе никаких проблем с дампами(как csv так и sql) или приложением, которое кстати и адаптировать пришлось аж в одном месте. Как легко догадаться этим местом был запрос с set names.
Но конечно некоторым балбесам удается указать поле latin1, запихать в него cp1251, а потом ругаться на мускул, который следует дословно их указаниям, вместо чудес телепатии. Кстати для таких в доке мускула тоже есть инструкция по исправлению подобных косяков.
>База UTF8, set names в кодировку исходного текста делал. при селекте данных
>вопросики. ЧЯДНТ? Тот же скрипт переделан на постгрес (заменены функции mysql_*
>на pgsql_*) - всё отлично.вот, подсказали - надо не в исходную set names делать
вот проверь свой create table statement:
show create table mytableтам должно быть что то вроде
CREATE TABLE `stats_global` (
`mailing_id` int(11) NOT NULL default '0',
`sentdate` datetime NOT NULL default '0000-00-00 00:00:00',
`html_sent` int(11) NOT NULL default '0',
`text_sent` int(11) NOT NULL default '0',
`html_read` int(11) NOT NULL default '0',
PRIMARY KEY (`mailing_id`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8;вот у тебя внизу наверняка не utf8, а cp1251, а ты лепишь инсерты с utf8
Да, про то, что кодировку на базу выставить недостаточно, надо на каждую таблицу отдельно (дополнительно к базе), это уже понятно. Собственно, требовалось: исходные данные в cp1251, табличные данные в базе - в UTF8. Вывод в последующем - в UTF8. Постгрес с задачей справился, но его у нас никто не знает, поддерживать придётся самому. А мускль выдает вопросы вместо букв. В общем, как была проблема с перекодировкой, так со времен древних релизов и осталась.
>Да, про то, что кодировку на базу выставить недостаточно, надо на каждую
>таблицу отдельно (дополнительно к базе), это уже понятно. Собственно, требовалось: исходные
>данные в cp1251, табличные данные в базе - в UTF8. Вывод
>в последующем - в UTF8. Постгрес с задачей справился, но его
>у нас никто не знает, поддерживать придётся самому. А мускль выдает
>вопросы вместо букв. В общем, как была проблема с перекодировкой, так
>со времен древних релизов и осталась.Разве н еочевидно, что база данных не имеет права тратить время на телепатию в виде автодетекта входной кодировки и автопреобразование в нужную?
Думаю, вам было бы полезно почитать man iconv
Читаем внимательнее, телепаты могут спать спокойно. Все нужные указания мусклю были даны: что в базе, что в принимаемых данных. Мускль тупо забил на эти указания.
>Читаем внимательнее, телепаты могут спать спокойно. Все нужные указания мусклю были даны:
>что в базе, что в принимаемых данных. Мускль тупо забил на
>эти указания.Вы же сами сказали - база utf8 (включая таблицы) а вы совали cp1251. Это нормально, что у вас получаются вопросики.
>>Читаем внимательнее, телепаты могут спать спокойно. Все нужные указания мусклю были даны:
>>что в базе, что в принимаемых данных. Мускль тупо забил на
>>эти указания.
>
>Вы же сами сказали - база utf8 (включая таблицы) а вы совали
>cp1251. Это нормально, что у вас получаются вопросики.Вот спецом сейчас проверил, благо сайты переезжают с виртуалки на дедик сегодня. Есть один сайт с мордой и базой в cp1251. Короче вопросики получил, так как вверху mysqldump файла стояло set names utf8 - когда поменял на set names cp1251, внутри базы все стало ок. Однако морда стала почти-адекватной только в utf8. Когда я допили файл CMS, отвечающий за открытие БД, и прописал первым запрос set names cp1251, сайт наконец стал адекватным в cp1251.
В общем идите курите, это проблема ваших кривых рук - вы просто не умеете пользоваться MySQL.
А тест к тому же доказал: set names нужно на вход и на чтение дергать.
mysql> select * from directions limit 10;
+-----+--------+
| id | name |
+-----+--------+
| 749 | ?????? |
| 750 | ?????? |
| 751 | ?????? |
| 752 | ?????? |
| 753 | ?????? |
| 754 | ?????? |
| 755 | ?????? |
| 756 | ?????? |
| 757 | ?????? |
| 758 | ?????? |
+-----+--------+
10 rows in set (0.00 sec)
------------------
Server version: 5.1.30-community MySQL Community Server (GPL)
Protocol version: 10
Connection: localhost via TCP/IP
Server characterset: utf8
Db characterset: utf8
Client characterset: utf8
Conn. characterset: utf8
------------------
CREATE TABLE `directions` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`name` varchar(255) CHARACTER SET latin1 DEFAULT NULL,
PRIMARY KEY (`id`)
) ENGINE=MyISAM AUTO_INCREMENT=1123 DEFAULT CHARSET=utf8 AVG_ROW_LENGTH=24;
------------------
Данные пихались простеньким рнр-скриптом, которые сразу после коннекта выполнял set names cp1251, получал данные из csv, выдирал нужные поля и скидывал в базу.
Заметил сейчас, оно выставило на столбец latin1. Возможно, был не прав, но это же п**дец, господа. Бегать по всей БД рекурсивно и менять кодировку каждому элементу, чтобы вдруг-чего-не-выставилось-в-дураццкий-дефолт...
Вот интересно, ты с postgres перед тем как работать тоже ни разу в мануал не заглянул? :)
>Заметил сейчас, оно выставило на столбец latin1. Возможно, был не прав, но
>это же п**дец, господа. Бегать по всей БД рекурсивно и менять
>кодировку каждому элементу, чтобы вдруг-чего-не-выставилось-в-дураццкий-дефолт...Очень рад, что вы все же соизволили разобраться в вопросе. Потому что из-за таких лентяев и появляются не адекватные отзывы в адрес хороших продуктов.
>Да, про то, что кодировку на базу выставить недостаточно, надо на каждую
>таблицу отдельно (дополнительно к базе), это уже понятно. Собственно, требовалось: исходные
>данные в cp1251, табличные данные в базе - в UTF8. Вывод
>в последующем - в UTF8. Постгрес с задачей справился, но его
>у нас никто не знает, поддерживать придётся самому. А мускль выдает
>вопросы вместо букв. В общем, как была проблема с перекодировкой, так
>со времен древних релизов и осталась.Да не важно, в какой кодировке данные в базе. Если нужно вставлять в кодировке X, то перед вставкой - set names X. Если нужно получать в кодировке X - то перед селектами set names X.
А кодировку на таблицу можно не выставлять - таблица наследует кодировку от базы, столбцы в таблице - от самой таблицы.
> включающей в себя два новых движка - Falcon и MariaЭто особенно забавно в свете того, что основные разработчики Maria теперь работают в Monty AB
А учтя что если ничего не сорвется то оракл будет хавать санки - очень интересно как это они в бардаке от перетрясок вдруг смогут часто релизить что-то качественное и быстро.Декларации это круто.Ну а что будет на практике - посмотрим...
Сдается мне, что пользуясь суматохой в связи с покупкой Sun'а разработчики MySQL пытаются реформировать процесс разработки. Community версию реанимировали, давно набившие оскомину девелоперские ветки в нормальный вид привели. В sun-е сейчас золотой месяц, старому руководству уже на все наплевать, можно самые смелые идеи протолкнуть.
Ага, плюс влили патчи от гугла в ветку 5.4, в общем очень радует происходящее.
Inside info:Sun давно уже пытается реформировать процесс MySQL - сейчас стали видны результаты и для "внешних" потребителей.