URL: https://www.opennet.me/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID3
Нить номер: 54770
[ Назад ]

Исходное сообщение
"MySQL меняет подход к подготовке тестовых версий. Выход MySQ..."

Отправлено opennews , 23-Май-09 09:42 
Представлен (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
Новость: http://www.opennet.me/opennews/art.shtml?num=21859


Содержание

Сообщения в этом обсуждении
"MySQL меняет подход к подготовке тестовых версий. Выход MySQ..."
Отправлено GateKeeper , 23-Май-09 09:42 
Кто знает, в MySQL уже починили вопросики?

"MySQL меняет подход к подготовке тестовых версий. Выход MySQ..."
Отправлено хзкто , 23-Май-09 10:31 
что вы имеете ввиду?

"MySQL меняет подход к подготовке тестовых версий. Выход MySQ..."
Отправлено _ , 23-Май-09 15:42 
Почини себе руки и поставь нормальную кодировку на базу/коннект/сервер.

"MySQL меняет подход к подготовке тестовых версий. Выход MySQ..."
Отправлено нео , 23-Май-09 16:05 
SET NAMES UTF8/CP1251/....(ненужное убрать) не пробовал?

"MySQL меняет подход к подготовке тестовых версий. Выход MySQ..."
Отправлено GateKeeper , 24-Май-09 01:04 
База UTF8, set names в кодировку исходного текста делал. при селекте данных вопросики. ЧЯДНТ? Тот же скрипт переделан на постгрес (заменены функции mysql_* на pgsql_*) - всё отлично.

"MySQL меняет подход к подготовке тестовых версий. Выход MySQ..."
Отправлено нео , 24-Май-09 01:21 
осталось открыть секред - какая CMS?

"MySQL меняет подход к подготовке тестовых версий. Выход MySQ..."
Отправлено Аноним , 24-Май-09 01:22 
set names делать надо не в "исходную", а в ту кодировку, в которой хочешь получать ответы.

"MySQL меняет подход к подготовке тестовых версий. Выход MySQ..."
Отправлено GateKeeper , 24-Май-09 13:57 
>set names делать надо не в "исходную", а в ту кодировку, в
>которой хочешь получать ответы.

Ответы на что, на INSERT INTO ... ?

Ниже писал уже: исходные данные в csv (экспорт из епселя), кодировка 1251, это парсится и пихается в базу. База UTF8, таблицы каждая в отдельности тоже UTF8 (приятный гемор, чОткий ход разработчиков, в этом месте было уже весело), скрипт-парсер выставляет set names в 1251, при селекте - вопросы. Повторяю, проблема с перекодировками, она у них генетическая, похоже. Выставлять кодировку на всю СУБД (о ужас) не предлагать, случай как раз из серии тех, когда это не подходит.

Почему такого геморроя нет в постгресе? И не надо брызгать слюной, как один молодой и неокрепший выше, я _хочу_ использовать mysql, поскольку наши девелоперы (которым в дальнейшем сопровождать) с ним хоть немного но знакомы, но эти особенности не могут мне позволить этого сделать.


"MySQL меняет подход к подготовке тестовых версий. Выход MySQ..."
Отправлено Аноним , 24-Май-09 18:17 
>Ответы на что, на INSERT INTO ... ?

Ответы на селекты. Если база utf8, скрипт вставки выставил set names cp1251 и передает данные в cp1251 - то в базу всё попадает правильно (т. е. конвертится в ту кодировку, в которой таблицы - utf8 в данном случае). Скрипт который делает селекты должен выставить set names в ту кодировку, в которой хочет данные получать.

>Почему такого геморроя нет в постгресе? И не надо брызгать слюной, как
>один молодой и неокрепший выше, я _хочу_ использовать mysql, поскольку наши
>девелоперы (которым в дальнейшем сопровождать) с ним хоть немного но знакомы,
>но эти особенности не могут мне позволить этого сделать.

Это не геморрой, просто один раз достаточно понять, как в mysql построена работа с кодировками. На самом-то деле проблема гроша выеденного не стоит. Единственный реальный косяк с их стороны был в миграции с 4.0 на старшие ветки, но это уже в далеком прошлом. Ну и может недостаточно хорошо в мануале все написали.

И кстати возможность контролировать кодировку вплоть до столбцов в одной таблице в некоторых ситуациях очень и очень выручает.


"MySQL меняет подход к подготовке тестовых версий. Выход MySQ..."
Отправлено angra , 25-Май-09 09:40 
>Повторяю, проблема с перекодировками, она у них генетическая, похоже

Проблема в ДНК тут скорее у того, кто не осилил чтение документации, а вместо себя винит разработчиков. Почему-то у тех, кто затратил хоть немного времени на беглый просмотр доки по этому вопросу, проблем с кодировками в мускуле не возникает. Причем в куда более экзотических случаях. Также не стоит ругаться на фичи, если их не понимаешь. Не нужны тебе, так не используй, никто за уши не тянет. А вот мне приходилось работать с базой, где поля в пределах одной таблицы имели разную кодировку. И представь себе никаких проблем с дампами(как csv так и sql) или приложением, которое кстати и адаптировать пришлось аж в одном месте. Как легко догадаться этим местом был запрос с set names.
Но конечно некоторым балбесам удается указать поле latin1, запихать в него cp1251, а потом ругаться на мускул, который следует дословно их указаниям, вместо чудес телепатии. Кстати для таких в доке мускула тоже есть инструкция по исправлению подобных косяков.


"MySQL меняет подход к подготовке тестовых версий. Выход MySQ..."
Отправлено нео , 24-Май-09 01:58 
>База 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


"MySQL меняет подход к подготовке тестовых версий. Выход MySQ..."
Отправлено GateKeeper , 24-Май-09 09:44 
Да, про то, что кодировку на базу выставить недостаточно, надо на каждую таблицу отдельно (дополнительно к базе), это уже понятно. Собственно, требовалось: исходные данные в cp1251, табличные данные в базе - в UTF8. Вывод в последующем - в UTF8. Постгрес с задачей справился, но его у нас никто не знает, поддерживать придётся самому. А мускль выдает вопросы вместо букв. В общем, как была проблема с перекодировкой, так со времен древних релизов и осталась.

"MySQL меняет подход к подготовке тестовых версий. Выход MySQ..."
Отправлено нео , 24-Май-09 14:35 
>Да, про то, что кодировку на базу выставить недостаточно, надо на каждую
>таблицу отдельно (дополнительно к базе), это уже понятно. Собственно, требовалось: исходные
>данные в cp1251, табличные данные в базе - в UTF8. Вывод
>в последующем - в UTF8. Постгрес с задачей справился, но его
>у нас никто не знает, поддерживать придётся самому. А мускль выдает
>вопросы вместо букв. В общем, как была проблема с перекодировкой, так
>со времен древних релизов и осталась.

Разве н еочевидно, что база данных не имеет права тратить время на телепатию в виде автодетекта входной кодировки и автопреобразование в нужную?

Думаю, вам было бы полезно почитать man iconv


"MySQL меняет подход к подготовке тестовых версий. Выход MySQ..."
Отправлено GateKeeper , 24-Май-09 15:38 
Читаем внимательнее, телепаты могут спать спокойно. Все нужные указания мусклю были даны: что в базе, что в принимаемых данных. Мускль тупо забил на эти указания.

"MySQL меняет подход к подготовке тестовых версий. Выход MySQ..."
Отправлено нео , 24-Май-09 17:39 
>Читаем внимательнее, телепаты могут спать спокойно. Все нужные указания мусклю были даны:
>что в базе, что в принимаемых данных. Мускль тупо забил на
>эти указания.

Вы же сами сказали - база utf8 (включая таблицы) а вы совали cp1251. Это нормально, что у вас получаются вопросики.


"MySQL меняет подход к подготовке тестовых версий. Выход MySQ..."
Отправлено нео , 24-Май-09 18:13 
>>Читаем внимательнее, телепаты могут спать спокойно. Все нужные указания мусклю были даны:
>>что в базе, что в принимаемых данных. Мускль тупо забил на
>>эти указания.
>
>Вы же сами сказали - база utf8 (включая таблицы) а вы совали
>cp1251. Это нормально, что у вас получаются вопросики.

Вот спецом сейчас проверил, благо сайты переезжают с виртуалки на дедик сегодня. Есть один сайт с мордой и базой в cp1251. Короче вопросики получил, так как вверху mysqldump файла стояло set names utf8 - когда поменял на set names cp1251, внутри базы все стало ок. Однако морда стала почти-адекватной только в utf8. Когда я допили файл CMS, отвечающий за открытие БД, и прописал первым запрос set names cp1251, сайт наконец стал адекватным в cp1251.

В общем идите курите, это проблема ваших кривых рук - вы просто не умеете пользоваться MySQL.

А тест к тому же доказал: set names нужно на вход и на чтение дергать.


"MySQL меняет подход к подготовке тестовых версий. Выход MySQ..."
Отправлено GateKeeper , 25-Май-09 08:44 
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, выдирал нужные поля и скидывал в базу.

"MySQL меняет подход к подготовке тестовых версий. Выход MySQ..."
Отправлено GateKeeper , 25-Май-09 08:47 
Заметил сейчас, оно выставило на столбец latin1. Возможно, был не прав, но это же п**дец, господа. Бегать по всей БД рекурсивно и менять кодировку каждому элементу, чтобы вдруг-чего-не-выставилось-в-дураццкий-дефолт...

"MySQL меняет подход к подготовке тестовых версий. Выход MySQ..."
Отправлено Аноним , 25-Май-09 15:17 
Вот интересно, ты с postgres перед тем как работать тоже ни разу в мануал не заглянул? :)

"MySQL меняет подход к подготовке тестовых версий. Выход MySQ..."
Отправлено нео , 25-Май-09 16:53 
>Заметил сейчас, оно выставило на столбец latin1. Возможно, был не прав, но
>это же п**дец, господа. Бегать по всей БД рекурсивно и менять
>кодировку каждому элементу, чтобы вдруг-чего-не-выставилось-в-дураццкий-дефолт...

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


"MySQL меняет подход к подготовке тестовых версий. Выход MySQ..."
Отправлено Аноним , 24-Май-09 18:22 
>Да, про то, что кодировку на базу выставить недостаточно, надо на каждую
>таблицу отдельно (дополнительно к базе), это уже понятно. Собственно, требовалось: исходные
>данные в cp1251, табличные данные в базе - в UTF8. Вывод
>в последующем - в UTF8. Постгрес с задачей справился, но его
>у нас никто не знает, поддерживать придётся самому. А мускль выдает
>вопросы вместо букв. В общем, как была проблема с перекодировкой, так
>со времен древних релизов и осталась.

Да не важно, в какой кодировке данные в базе. Если нужно вставлять в кодировке X, то перед вставкой - set names X. Если нужно получать в кодировке X - то перед селектами set names X.

А кодировку на таблицу можно не выставлять - таблица наследует кодировку от базы, столбцы в таблице - от самой таблицы.


"MySQL меняет подход к подготовке тестовых версий. Выход MySQ..."
Отправлено vadiml , 23-Май-09 09:54 
> включающей в себя два новых движка - Falcon и Maria

Это особенно забавно в свете того, что основные разработчики Maria теперь работают в Monty AB


"MySQL меняет подход к подготовке тестовых версий. Выход MySQ..."
Отправлено User294 , 23-Май-09 14:36 
А учтя что если ничего не сорвется то оракл будет хавать санки - очень интересно как это они в бардаке от перетрясок вдруг смогут часто релизить что-то качественное и быстро.Декларации это круто.Ну а что будет на практике - посмотрим...

"MySQL меняет подход к подготовке тестовых версий. Выход MySQ..."
Отправлено uldus , 23-Май-09 21:48 
Сдается мне, что пользуясь суматохой в связи с покупкой Sun'а разработчики MySQL пытаются реформировать процесс разработки. Community версию реанимировали, давно набившие оскомину девелоперские ветки в нормальный вид привели. В sun-е сейчас золотой месяц, старому руководству уже на все наплевать, можно самые смелые идеи протолкнуть.


"MySQL меняет подход к подготовке тестовых версий. Выход MySQ..."
Отправлено Аноним , 24-Май-09 01:24 
Ага, плюс влили патчи от гугла в ветку 5.4, в общем очень радует происходящее.

"MySQL меняет подход к подготовке тестовых версий. Выход MySQ..."
Отправлено uZver , 25-Май-09 10:39 
Inside info:

Sun давно уже пытается реформировать процесс MySQL - сейчас стали видны результаты и для "внешних" потребителей.