forum.opennet.ru - "MySQL меняет подход к подготовке тестовых версий. Выход MySQ..." (26)

форумы

помощь

поиск

регистрация

майллист

вход/выход

слежка

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

Форумы Разговоры, обсуждение новостей (Public)
Вариант для распечатки		Пред. тема \| След. тема
Изначальное сообщение		[ Отслеживать ]

"MySQL меняет подход к подготовке тестовых версий. Выход MySQ..."		+/–
Сообщение от opennews (??) on 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.ru/opennews/art.shtml?num=21859
Высказать мнение \| Ответить \| Правка \| Cообщить модератору

Оглавление

MySQL меняет подход к подготовке тестовых версий. Выход MySQ..., GateKeeper, 09:42 , 23-Май-09, (1) –4

MySQL меняет подход к подготовке тестовых версий. Выход MySQ..., хзкто, 10:31 , 23-Май-09, (4)
MySQL меняет подход к подготовке тестовых версий. Выход MySQ..., _, 15:42 , 23-Май-09, (6)
MySQL меняет подход к подготовке тестовых версий. Выход MySQ..., нео, 16:05 , 23-Май-09, (7)

MySQL меняет подход к подготовке тестовых версий. Выход MySQ..., GateKeeper, 01:04 , 24-Май-09, (10)

MySQL меняет подход к подготовке тестовых версий. Выход MySQ..., нео, 01:21 , 24-Май-09, (11)
MySQL меняет подход к подготовке тестовых версий. Выход MySQ..., Аноним, 01:22 , 24-Май-09, (12)

MySQL меняет подход к подготовке тестовых версий. Выход MySQ..., GateKeeper, 13:57 , 24-Май-09, (16)

MySQL меняет подход к подготовке тестовых версий. Выход MySQ..., Аноним, 18:17 , 24-Май-09, (21)
MySQL меняет подход к подготовке тестовых версий. Выход MySQ..., angra, 09:40 , 25-Май-09, (25)

MySQL меняет подход к подготовке тестовых версий. Выход MySQ..., нео, 01:58 , 24-Май-09, (14)

MySQL меняет подход к подготовке тестовых версий. Выход MySQ..., GateKeeper, 09:44 , 24-Май-09, (15)

MySQL меняет подход к подготовке тестовых версий. Выход MySQ..., нео, 14:35 , 24-Май-09, (17)

MySQL меняет подход к подготовке тестовых версий. Выход MySQ..., GateKeeper, 15:38 , 24-Май-09, (18) –1

MySQL меняет подход к подготовке тестовых версий. Выход MySQ..., нео, 17:39 , 24-Май-09, (19)

MySQL меняет подход к подготовке тестовых версий. Выход MySQ..., нео, 18:13 , 24-Май-09, (20) +1

MySQL меняет подход к подготовке тестовых версий. Выход MySQ..., GateKeeper, 08:44 , 25-Май-09, (23)

MySQL меняет подход к подготовке тестовых версий. Выход MySQ..., GateKeeper, 08:47 , 25-Май-09, (24)

MySQL меняет подход к подготовке тестовых версий. Выход MySQ..., Аноним, 15:17 , 25-Май-09, (27)
MySQL меняет подход к подготовке тестовых версий. Выход MySQ..., нео, 16:53 , 25-Май-09, (28)

MySQL меняет подход к подготовке тестовых версий. Выход MySQ..., Аноним, 18:22 , 24-Май-09, (22)

MySQL меняет подход к подготовке тестовых версий. Выход MySQ..., vadiml, 09:54 , 23-Май-09, (3)

MySQL меняет подход к подготовке тестовых версий. Выход MySQ..., User294, 14:36 , 23-Май-09, (5)

MySQL меняет подход к подготовке тестовых версий. Выход MySQ..., uldus, 21:48 , 23-Май-09, (9)

MySQL меняет подход к подготовке тестовых версий. Выход MySQ..., Аноним, 01:24 , 24-Май-09, (13) +1
MySQL меняет подход к подготовке тестовых версий. Выход MySQ..., uZver, 10:39 , 25-Май-09, (26)

Сообщения по теме [Сортировка по времени | RSS]

1. "MySQL меняет подход к подготовке тестовых версий. Выход MySQ..." –4 +/–

Сообщение от GateKeeper (??) on 23-Май-09, 09:42

Кто знает, в MySQL уже починили вопросики?

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

4. "MySQL меняет подход к подготовке тестовых версий. Выход MySQ..." +/–

Сообщение от хзкто on 23-Май-09, 10:31

что вы имеете ввиду?

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

6. "MySQL меняет подход к подготовке тестовых версий. Выход MySQ..." +/–

Сообщение от _ (??) on 23-Май-09, 15:42

Почини себе руки и поставь нормальную кодировку на базу/коннект/сервер.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

7. "MySQL меняет подход к подготовке тестовых версий. Выход MySQ..." +/–

Сообщение от нео on 23-Май-09, 16:05

SET NAMES UTF8/CP1251/....(ненужное убрать) не пробовал?

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

10. "MySQL меняет подход к подготовке тестовых версий. Выход MySQ..." +/–

Сообщение от GateKeeper (??) on 24-Май-09, 01:04

База UTF8, set names в кодировку исходного текста делал. при селекте данных вопросики. ЧЯДНТ? Тот же скрипт переделан на постгрес (заменены функции mysql_* на pgsql_*) - всё отлично.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

11. "MySQL меняет подход к подготовке тестовых версий. Выход MySQ..." +/–

Сообщение от нео on 24-Май-09, 01:21

осталось открыть секред - какая CMS?

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

12. "MySQL меняет подход к подготовке тестовых версий. Выход MySQ..." +/–

Сообщение от Аноним (??) on 24-Май-09, 01:22

set names делать надо не в "исходную", а в ту кодировку, в которой хочешь получать ответы.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

16. "MySQL меняет подход к подготовке тестовых версий. Выход MySQ..." +/–

Сообщение от GateKeeper (??) on 24-Май-09, 13:57

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

21. "MySQL меняет подход к подготовке тестовых версий. Выход MySQ..." +/–

Сообщение от Аноним (??) on 24-Май-09, 18:17

>Ответы на что, на INSERT INTO ... ?
Ответы на селекты. Если база utf8, скрипт вставки выставил set names cp1251 и передает данные в cp1251 - то в базу всё попадает правильно (т. е. конвертится в ту кодировку, в которой таблицы - utf8 в данном случае). Скрипт который делает селекты должен выставить set names в ту кодировку, в которой хочет данные получать.
>Почему такого геморроя нет в постгресе? И не надо брызгать слюной, как
>один молодой и неокрепший выше, я _хочу_ использовать mysql, поскольку наши
>девелоперы (которым в дальнейшем сопровождать) с ним хоть немного но знакомы,
>но эти особенности не могут мне позволить этого сделать.
Это не геморрой, просто один раз достаточно понять, как в mysql построена работа с кодировками. На самом-то деле проблема гроша выеденного не стоит. Единственный реальный косяк с их стороны был в миграции с 4.0 на старшие ветки, но это уже в далеком прошлом. Ну и может недостаточно хорошо в мануале все написали.
И кстати возможность контролировать кодировку вплоть до столбцов в одной таблице в некоторых ситуациях очень и очень выручает.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

25. "MySQL меняет подход к подготовке тестовых версий. Выход MySQ..." +/–

Сообщение от angra (ok) on 25-Май-09, 09:40

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

14. "MySQL меняет подход к подготовке тестовых версий. Выход MySQ..." +/–

Сообщение от нео on 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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

15. "MySQL меняет подход к подготовке тестовых версий. Выход MySQ..." +/–

Сообщение от GateKeeper (??) on 24-Май-09, 09:44

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

17. "MySQL меняет подход к подготовке тестовых версий. Выход MySQ..." +/–

Сообщение от нео on 24-Май-09, 14:35

>Да, про то, что кодировку на базу выставить недостаточно, надо на каждую
>таблицу отдельно (дополнительно к базе), это уже понятно. Собственно, требовалось: исходные
>данные в cp1251, табличные данные в базе - в UTF8. Вывод
>в последующем - в UTF8. Постгрес с задачей справился, но его
>у нас никто не знает, поддерживать придётся самому. А мускль выдает
>вопросы вместо букв. В общем, как была проблема с перекодировкой, так
>со времен древних релизов и осталась.
Разве н еочевидно, что база данных не имеет права тратить время на телепатию в виде автодетекта входной кодировки и автопреобразование в нужную?
Думаю, вам было бы полезно почитать man iconv

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

18. "MySQL меняет подход к подготовке тестовых версий. Выход MySQ..." –1 +/–

Сообщение от GateKeeper (??) on 24-Май-09, 15:38

Читаем внимательнее, телепаты могут спать спокойно. Все нужные указания мусклю были даны: что в базе, что в принимаемых данных. Мускль тупо забил на эти указания.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

19. "MySQL меняет подход к подготовке тестовых версий. Выход MySQ..." +/–

Сообщение от нео on 24-Май-09, 17:39

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

20. "MySQL меняет подход к подготовке тестовых версий. Выход MySQ..." +1 +/–

Сообщение от нео on 24-Май-09, 18:13

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

23. "MySQL меняет подход к подготовке тестовых версий. Выход MySQ..." +/–

Сообщение от GateKeeper (??) on 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, выдирал нужные поля и скидывал в базу.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

24. "MySQL меняет подход к подготовке тестовых версий. Выход MySQ..." +/–

Сообщение от GateKeeper (??) on 25-Май-09, 08:47

Заметил сейчас, оно выставило на столбец latin1. Возможно, был не прав, но это же п**дец, господа. Бегать по всей БД рекурсивно и менять кодировку каждому элементу, чтобы вдруг-чего-не-выставилось-в-дураццкий-дефолт...

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

27. "MySQL меняет подход к подготовке тестовых версий. Выход MySQ..." +/–

Сообщение от Аноним (??) on 25-Май-09, 15:17

Вот интересно, ты с postgres перед тем как работать тоже ни разу в мануал не заглянул? :)

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

28. "MySQL меняет подход к подготовке тестовых версий. Выход MySQ..." +/–

Сообщение от нео on 25-Май-09, 16:53

>Заметил сейчас, оно выставило на столбец latin1. Возможно, был не прав, но
>это же п**дец, господа. Бегать по всей БД рекурсивно и менять
>кодировку каждому элементу, чтобы вдруг-чего-не-выставилось-в-дураццкий-дефолт...
Очень рад, что вы все же соизволили разобраться в вопросе. Потому что из-за таких лентяев и появляются не адекватные отзывы в адрес хороших продуктов.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

22. "MySQL меняет подход к подготовке тестовых версий. Выход MySQ..." +/–

Сообщение от Аноним (??) on 24-Май-09, 18:22

>Да, про то, что кодировку на базу выставить недостаточно, надо на каждую
>таблицу отдельно (дополнительно к базе), это уже понятно. Собственно, требовалось: исходные
>данные в cp1251, табличные данные в базе - в UTF8. Вывод
>в последующем - в UTF8. Постгрес с задачей справился, но его
>у нас никто не знает, поддерживать придётся самому. А мускль выдает
>вопросы вместо букв. В общем, как была проблема с перекодировкой, так
>со времен древних релизов и осталась.
Да не важно, в какой кодировке данные в базе. Если нужно вставлять в кодировке X, то перед вставкой - set names X. Если нужно получать в кодировке X - то перед селектами set names X.
А кодировку на таблицу можно не выставлять - таблица наследует кодировку от базы, столбцы в таблице - от самой таблицы.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

3. "MySQL меняет подход к подготовке тестовых версий. Выход MySQ..." +/–

Сообщение от vadiml on 23-Май-09, 09:54

> включающей в себя два новых движка - Falcon и Maria
Это особенно забавно в свете того, что основные разработчики Maria теперь работают в Monty AB

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

5. "MySQL меняет подход к подготовке тестовых версий. Выход MySQ..." +/–

Сообщение от User294 (??) on 23-Май-09, 14:36

А учтя что если ничего не сорвется то оракл будет хавать санки - очень интересно как это они в бардаке от перетрясок вдруг смогут часто релизить что-то качественное и быстро.Декларации это круто.Ну а что будет на практике - посмотрим...

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

9. "MySQL меняет подход к подготовке тестовых версий. Выход MySQ..." +/–

Сообщение от uldus (ok) on 23-Май-09, 21:48

Сдается мне, что пользуясь суматохой в связи с покупкой Sun'а разработчики MySQL пытаются реформировать процесс разработки. Community версию реанимировали, давно набившие оскомину девелоперские ветки в нормальный вид привели. В sun-е сейчас золотой месяц, старому руководству уже на все наплевать, можно самые смелые идеи протолкнуть.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

13. "MySQL меняет подход к подготовке тестовых версий. Выход MySQ..." +1 +/–

Сообщение от Аноним (??) on 24-Май-09, 01:24

Ага, плюс влили патчи от гугла в ветку 5.4, в общем очень радует происходящее.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

26. "MySQL меняет подход к подготовке тестовых версий. Выход MySQ..." +/–

Сообщение от uZver (ok) on 25-Май-09, 10:39

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Индекс форумов | Темы | Пред. тема | След. тема

Оцените тред (1=ужас, 5=супер)? [ 1 | 2 | 3 | 4 | 5 ] [Рекомендовать для помещения в FAQ]

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

1. "MySQL меняет подход к подготовке тестовых версий. Выход MySQ..."		–4 +/–
Сообщение от GateKeeper (??) on 23-Май-09, 09:42
Кто знает, в MySQL уже починили вопросики?
Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	4. "MySQL меняет подход к подготовке тестовых версий. Выход MySQ..."		+/–
	Сообщение от хзкто on 23-Май-09, 10:31
	что вы имеете ввиду?
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	6. "MySQL меняет подход к подготовке тестовых версий. Выход MySQ..."		+/–
	Сообщение от _ (??) on 23-Май-09, 15:42
	Почини себе руки и поставь нормальную кодировку на базу/коннект/сервер.
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	7. "MySQL меняет подход к подготовке тестовых версий. Выход MySQ..."		+/–
	Сообщение от нео on 23-Май-09, 16:05
	SET NAMES UTF8/CP1251/....(ненужное убрать) не пробовал?
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


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


	11. "MySQL меняет подход к подготовке тестовых версий. Выход MySQ..."		+/–
	Сообщение от нео on 24-Май-09, 01:21
	осталось открыть секред - какая CMS?
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	12. "MySQL меняет подход к подготовке тестовых версий. Выход MySQ..."		+/–
	Сообщение от Аноним (??) on 24-Май-09, 01:22
	set names делать надо не в "исходную", а в ту кодировку, в которой хочешь получать ответы.
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	16. "MySQL меняет подход к подготовке тестовых версий. Выход MySQ..."		+/–
	Сообщение от GateKeeper (??) on 24-Май-09, 13:57
	>set names делать надо не в "исходную", а в ту кодировку, в >которой хочешь получать ответы. Ответы на что, на INSERT INTO ... ? Ниже писал уже: исходные данные в csv (экспорт из епселя), кодировка 1251, это парсится и пихается в базу. База UTF8, таблицы каждая в отдельности тоже UTF8 (приятный гемор, чОткий ход разработчиков, в этом месте было уже весело), скрипт-парсер выставляет set names в 1251, при селекте - вопросы. Повторяю, проблема с перекодировками, она у них генетическая, похоже. Выставлять кодировку на всю СУБД (о ужас) не предлагать, случай как раз из серии тех, когда это не подходит. Почему такого геморроя нет в постгресе? И не надо брызгать слюной, как один молодой и неокрепший выше, я _хочу_ использовать mysql, поскольку наши девелоперы (которым в дальнейшем сопровождать) с ним хоть немного но знакомы, но эти особенности не могут мне позволить этого сделать.
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	21. "MySQL меняет подход к подготовке тестовых версий. Выход MySQ..."		+/–
	Сообщение от Аноним (??) on 24-Май-09, 18:17
	>Ответы на что, на INSERT INTO ... ? Ответы на селекты. Если база utf8, скрипт вставки выставил set names cp1251 и передает данные в cp1251 - то в базу всё попадает правильно (т. е. конвертится в ту кодировку, в которой таблицы - utf8 в данном случае). Скрипт который делает селекты должен выставить set names в ту кодировку, в которой хочет данные получать. >Почему такого геморроя нет в постгресе? И не надо брызгать слюной, как >один молодой и неокрепший выше, я _хочу_ использовать mysql, поскольку наши >девелоперы (которым в дальнейшем сопровождать) с ним хоть немного но знакомы, >но эти особенности не могут мне позволить этого сделать. Это не геморрой, просто один раз достаточно понять, как в mysql построена работа с кодировками. На самом-то деле проблема гроша выеденного не стоит. Единственный реальный косяк с их стороны был в миграции с 4.0 на старшие ветки, но это уже в далеком прошлом. Ну и может недостаточно хорошо в мануале все написали. И кстати возможность контролировать кодировку вплоть до столбцов в одной таблице в некоторых ситуациях очень и очень выручает.
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	25. "MySQL меняет подход к подготовке тестовых версий. Выход MySQ..."		+/–
	Сообщение от angra (ok) on 25-Май-09, 09:40
	>Повторяю, проблема с перекодировками, она у них генетическая, похоже Проблема в ДНК тут скорее у того, кто не осилил чтение документации, а вместо себя винит разработчиков. Почему-то у тех, кто затратил хоть немного времени на беглый просмотр доки по этому вопросу, проблем с кодировками в мускуле не возникает. Причем в куда более экзотических случаях. Также не стоит ругаться на фичи, если их не понимаешь. Не нужны тебе, так не используй, никто за уши не тянет. А вот мне приходилось работать с базой, где поля в пределах одной таблицы имели разную кодировку. И представь себе никаких проблем с дампами(как csv так и sql) или приложением, которое кстати и адаптировать пришлось аж в одном месте. Как легко догадаться этим местом был запрос с set names. Но конечно некоторым балбесам удается указать поле latin1, запихать в него cp1251, а потом ругаться на мускул, который следует дословно их указаниям, вместо чудес телепатии. Кстати для таких в доке мускула тоже есть инструкция по исправлению подобных косяков.
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	14. "MySQL меняет подход к подготовке тестовых версий. Выход MySQ..."		+/–
	Сообщение от нео on 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
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


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


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


	18. "MySQL меняет подход к подготовке тестовых версий. Выход MySQ..."		–1 +/–
	Сообщение от GateKeeper (??) on 24-Май-09, 15:38
	Читаем внимательнее, телепаты могут спать спокойно. Все нужные указания мусклю были даны: что в базе, что в принимаемых данных. Мускль тупо забил на эти указания.
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	19. "MySQL меняет подход к подготовке тестовых версий. Выход MySQ..."		+/–
	Сообщение от нео on 24-Май-09, 17:39
	>Читаем внимательнее, телепаты могут спать спокойно. Все нужные указания мусклю были даны: >что в базе, что в принимаемых данных. Мускль тупо забил на >эти указания. Вы же сами сказали - база utf8 (включая таблицы) а вы совали cp1251. Это нормально, что у вас получаются вопросики.
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	20. "MySQL меняет подход к подготовке тестовых версий. Выход MySQ..."		+1 +/–
	Сообщение от нео on 24-Май-09, 18:13
	>>Читаем внимательнее, телепаты могут спать спокойно. Все нужные указания мусклю были даны: >>что в базе, что в принимаемых данных. Мускль тупо забил на >>эти указания. > >Вы же сами сказали - база utf8 (включая таблицы) а вы совали >cp1251. Это нормально, что у вас получаются вопросики. Вот спецом сейчас проверил, благо сайты переезжают с виртуалки на дедик сегодня. Есть один сайт с мордой и базой в cp1251. Короче вопросики получил, так как вверху mysqldump файла стояло set names utf8 - когда поменял на set names cp1251, внутри базы все стало ок. Однако морда стала почти-адекватной только в utf8. Когда я допили файл CMS, отвечающий за открытие БД, и прописал первым запрос set names cp1251, сайт наконец стал адекватным в cp1251. В общем идите курите, это проблема ваших кривых рук - вы просто не умеете пользоваться MySQL. А тест к тому же доказал: set names нужно на вход и на чтение дергать.
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	23. "MySQL меняет подход к подготовке тестовых версий. Выход MySQ..."		+/–
	Сообщение от GateKeeper (??) on 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, выдирал нужные поля и скидывал в базу.
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	24. "MySQL меняет подход к подготовке тестовых версий. Выход MySQ..."		+/–
	Сообщение от GateKeeper (??) on 25-Май-09, 08:47
	Заметил сейчас, оно выставило на столбец latin1. Возможно, был не прав, но это же п**дец, господа. Бегать по всей БД рекурсивно и менять кодировку каждому элементу, чтобы вдруг-чего-не-выставилось-в-дураццкий-дефолт...
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	27. "MySQL меняет подход к подготовке тестовых версий. Выход MySQ..."		+/–
	Сообщение от Аноним (??) on 25-Май-09, 15:17
	Вот интересно, ты с postgres перед тем как работать тоже ни разу в мануал не заглянул? :)
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	28. "MySQL меняет подход к подготовке тестовых версий. Выход MySQ..."		+/–
	Сообщение от нео on 25-Май-09, 16:53
	>Заметил сейчас, оно выставило на столбец latin1. Возможно, был не прав, но >это же п**дец, господа. Бегать по всей БД рекурсивно и менять >кодировку каждому элементу, чтобы вдруг-чего-не-выставилось-в-дураццкий-дефолт... Очень рад, что вы все же соизволили разобраться в вопросе. Потому что из-за таких лентяев и появляются не адекватные отзывы в адрес хороших продуктов.
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


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

3. "MySQL меняет подход к подготовке тестовых версий. Выход MySQ..."		+/–
Сообщение от vadiml on 23-Май-09, 09:54
> включающей в себя два новых движка - Falcon и Maria Это особенно забавно в свете того, что основные разработчики Maria теперь работают в Monty AB
Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	5. "MySQL меняет подход к подготовке тестовых версий. Выход MySQ..."		+/–
	Сообщение от User294 (??) on 23-Май-09, 14:36
	А учтя что если ничего не сорвется то оракл будет хавать санки - очень интересно как это они в бардаке от перетрясок вдруг смогут часто релизить что-то качественное и быстро.Декларации это круто.Ну а что будет на практике - посмотрим...
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору

9. "MySQL меняет подход к подготовке тестовых версий. Выход MySQ..."		+/–
Сообщение от uldus (ok) on 23-Май-09, 21:48
Сдается мне, что пользуясь суматохой в связи с покупкой Sun'а разработчики MySQL пытаются реформировать процесс разработки. Community версию реанимировали, давно набившие оскомину девелоперские ветки в нормальный вид привели. В sun-е сейчас золотой месяц, старому руководству уже на все наплевать, можно самые смелые идеи протолкнуть.
Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	13. "MySQL меняет подход к подготовке тестовых версий. Выход MySQ..."		+1 +/–
	Сообщение от Аноним (??) on 24-Май-09, 01:24
	Ага, плюс влили патчи от гугла в ветку 5.4, в общем очень радует происходящее.
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	26. "MySQL меняет подход к подготовке тестовых версий. Выход MySQ..."		+/–
	Сообщение от uZver (ok) on 25-Май-09, 10:39
	Inside info: Sun давно уже пытается реформировать процесс MySQL - сейчас стали видны результаты и для "внешних" потребителей.
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору

Архив \| Удалить	Индекс форумов \| Темы \| Пред. тема \| След. тема
Оцените тред (1=ужас, 5=супер)? [ 1 \| 2 \| 3 \| 4 \| 5 ] [Рекомендовать для помещения в FAQ]