![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
От жеж вуду
Решил разобраться с внутренним устройством баг-трекера на предмет его миграции с "автоматически инсталлированного под виндой" на "поставленный вручную на дебиане".
Обнаружил, что автоматический инсталлятор под виндой создал базу в 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 при импорте таки помогла - новая база стала в правильной кодировке.
no subject
no subject
no subject
no subject
я ее поменял в последнюю очередь, но кроме этого, еще указал в опциях mysql --default-character-set=utf8, после чего все заработало.
no subject
- кодировка, в которой отдаётся аппликухе (SET NAMES)
- и кодировка в которой отдаёт апликуха.
Потёряться тут конечно можно, но лучше по возможности держать всё в одной кодировке :)
Гм, как то использовал команду для конвертации таблицы из одной кодировки в другую. ИМХО более правильный способ.
no subject
no subject
no subject
no subject
no subject
no subject
Для тех кто всё-таки читает:
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
no subject
no subject
Я обычно ранее чем через год-два на новые версии не хожу, во избежание - пусть другие сначала все баги отловят, пару багфикс-релизов сделают, а потом уж и я - на готовое:)
no subject
no subject
no subject
no subject
no subject
и в это прочее, между прочим входит то, что у вас таблицы скорее всего в myisam
no subject
no subject
no subject
no subject
no subject
да да да
сколько раз натыкался на такую хуйню ;]
no subject
Как минимум, один солидарный со мной человек тут есть ;-)
no subject
no subject
no subject
по поводу того, что я делал что-то не так, но
намучился я с ним, в своё время, весьмаа прилично.
А вот PostgreSQL, наоборот, принёс мне
большую радость и облегчение.
no subject
no subject
Сейчас уже практически все области его применения покрывает PostgreSQL.
Остальное покрывает sqlite.
Вообще, эта парочка, sqlite и PostgreSQL, покрывает оочень много применений SQL'я "вообще", за 2-мя исключениями.
Первое исключение касается сверх-больших-сложных баз, с которыми я не имел дел, и не имею права утверждать, что PostgreSQL тут годится. Хотя, наблюдения показывают, что вполне годится, и даже от оракла отстаёт уже не очень сильно.
Второе исключение касается сверх-навороченного OLAP, тут есть специально приспособленные под это конкурренты.
no subject
И вот такая вот штука: все мои задачи с базами - это антихайлоад. То есть, по производительности мускуль, постгре и оракл буду на них тупо равны. А скулайт - нет, потому что придётся делать дополнительные телодвижения для доступа нескольких процессов к одной базе.
На тех, кто делает на мускуле сверх-большие-сложные базы и сверх-навороченное OLAP, я хотел бы посмотреть. Чё-то мне не кажется, что это разумный выбор.
no subject
Как под виндовсом -- проще некуда,
так и под дженту -- очень просто.
Под дебианом не пробовал очень давно,
но не думаю, что заметно сложнее.
no subject
no subject
no subject
no subject