От жеж вуду
Apr. 13th, 2010 11:08 am![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
metaclassРешил разобраться с внутренним устройством баг-трекера на предмет его миграции с "автоматически инсталлированного под виндой" на "поставленный вручную на дебиане".
Обнаружил, что автоматический инсталлятор под виндой создал базу в mysql с кодировкой latin1, а рубирельсовое приложение при этом работает в кодировке utf8. Дамп базы вроде в utf8 получается, если поставить mysqldump кодировку latin1, но подгрузить этот дамп в utf8 базу у меня не выходит.
PS: фак мой мозг. Поставил для базы данных с default character set utf8 в конфиге рельсов encoding: latin1 - кодировка исправилась. Хер знает, что они там делают.
PPS: замена всех latin1 на utf8 в дампе, установка --default-character-set=utf8 при импорте таки помогла - новая база стала в правильной кодировке.
Обнаружил, что автоматический инсталлятор под виндой создал базу в mysql с кодировкой latin1, а рубирельсовое приложение при этом работает в кодировке utf8. Дамп базы вроде в utf8 получается, если поставить mysqldump кодировку latin1, но подгрузить этот дамп в utf8 базу у меня не выходит.
PS: фак мой мозг. Поставил для базы данных с default character set utf8 в конфиге рельсов encoding: latin1 - кодировка исправилась. Хер знает, что они там делают.
PPS: замена всех latin1 на utf8 в дампе, установка --default-character-set=utf8 при импорте таки помогла - новая база стала в правильной кодировке.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2010-04-13 11:19 am (UTC)no subject
Date: 2010-04-13 11:23 am (UTC)no subject
Date: 2010-04-13 11:28 am (UTC)no subject
Date: 2010-04-13 11:32 am (UTC)я ее поменял в последнюю очередь, но кроме этого, еще указал в опциях mysql --default-character-set=utf8, после чего все заработало.
no subject
Date: 2010-04-13 01:49 pm (UTC)- кодировка, в которой отдаётся аппликухе (SET NAMES)
- и кодировка в которой отдаёт апликуха.
Потёряться тут конечно можно, но лучше по возможности держать всё в одной кодировке :)
Гм, как то использовал команду для конвертации таблицы из одной кодировки в другую. ИМХО более правильный способ.
no subject
Date: 2010-04-13 01:58 pm (UTC)no subject
Date: 2010-04-13 11:20 am (UTC)no subject
Date: 2010-04-13 11:46 am (UTC)no subject
Date: 2010-04-13 12:07 pm (UTC)no subject
Date: 2010-04-13 01:51 pm (UTC)no subject
Date: 2010-04-13 03:50 pm (UTC)Для тех кто всё-таки читает:
http://www.postgresql.org/docs/8.4/interactive/sql-createdatabase.html
lc_collate
Collation order (LC_COLLATE) to use in the new database. This affects the sort order applied to strings, e.g. in queries with ORDER BY, as well as the order used in indexes on text columns. The default is to use the collation order of the template database. See below for additional restrictions.
lc_ctype
Character classification (LC_CTYPE) to use in the new database. This affects the categorization of characters, e.g. lower, upper and digit. The default is to use the character classification of the template database. See below for additional restrictions.
no subject
Date: 2010-04-13 04:18 pm (UTC)no subject
Date: 2010-04-13 04:23 pm (UTC)no subject
Date: 2010-04-13 06:28 pm (UTC)Я обычно ранее чем через год-два на новые версии не хожу, во избежание - пусть другие сначала все баги отловят, пару багфикс-релизов сделают, а потом уж и я - на готовое:)
no subject
Date: 2010-04-13 11:40 am (UTC)no subject
Date: 2010-04-13 01:50 pm (UTC)no subject
Date: 2010-04-13 01:58 pm (UTC)no subject
Date: 2010-04-13 03:38 pm (UTC)no subject
Date: 2010-04-13 03:42 pm (UTC)и в это прочее, между прочим входит то, что у вас таблицы скорее всего в myisam
no subject
Date: 2010-04-13 04:15 pm (UTC)no subject
Date: 2010-04-13 04:17 pm (UTC)no subject
Date: 2010-04-13 04:19 pm (UTC)no subject
Date: 2010-04-13 06:29 pm (UTC)no subject
Date: 2010-04-14 12:55 am (UTC)да да да
сколько раз натыкался на такую хуйню ;]
no subject
Date: 2010-04-13 07:15 pm (UTC)Как минимум, один солидарный со мной человек тут есть ;-)
no subject
Date: 2010-04-13 07:20 pm (UTC)no subject
Date: 2010-04-14 12:55 am (UTC)no subject
Date: 2010-04-14 06:36 am (UTC)по поводу того, что я делал что-то не так, но
намучился я с ним, в своё время, весьмаа прилично.
А вот PostgreSQL, наоборот, принёс мне
большую радость и облегчение.
no subject
Date: 2010-04-14 08:33 am (UTC)no subject
Date: 2010-04-14 10:27 am (UTC)Сейчас уже практически все области его применения покрывает PostgreSQL.
Остальное покрывает sqlite.
Вообще, эта парочка, sqlite и PostgreSQL, покрывает оочень много применений SQL'я "вообще", за 2-мя исключениями.
Первое исключение касается сверх-больших-сложных баз, с которыми я не имел дел, и не имею права утверждать, что PostgreSQL тут годится. Хотя, наблюдения показывают, что вполне годится, и даже от оракла отстаёт уже не очень сильно.
Второе исключение касается сверх-навороченного OLAP, тут есть специально приспособленные под это конкурренты.
no subject
Date: 2010-04-14 10:39 am (UTC)И вот такая вот штука: все мои задачи с базами - это антихайлоад. То есть, по производительности мускуль, постгре и оракл буду на них тупо равны. А скулайт - нет, потому что придётся делать дополнительные телодвижения для доступа нескольких процессов к одной базе.
На тех, кто делает на мускуле сверх-большие-сложные базы и сверх-навороченное OLAP, я хотел бы посмотреть. Чё-то мне не кажется, что это разумный выбор.
no subject
Date: 2010-04-14 10:47 am (UTC)Как под виндовсом -- проще некуда,
так и под дженту -- очень просто.
Под дебианом не пробовал очень давно,
но не думаю, что заметно сложнее.
no subject
Date: 2010-04-14 11:06 am (UTC)no subject
Date: 2010-04-14 11:51 am (UTC)no subject
Date: 2010-04-14 11:56 am (UTC)no subject
Date: 2010-04-16 10:21 pm (UTC)