BiTel

Доброе время суток!
Решил тут попробовать сабж.
Встретил одну непонятку...
моя база в cp1251.

В "Инструкции по обновлению с 3.5-6.1 до 6.2" читаем:
"... Там теперь characterEncoding=UTF-8 вместо cp1251. Но надо указать cp1251, если в вашей базе данных такая кодировка ...Если БД у вас в cp1251, то connectionCollation нужно указать соответствующий правильный (или удалить)"

в update_6.2.zip в patch.sql есть статемент:



Как-то странно для cp1251 иметь такую collate , не ?

_________________
"Все правые - в резерве!" (c) (translate.google.ru/#en/ru/all%20rigths%20reserved)

Не, просто крайне рекомендуется перевести базу в UTF-8. Ну и не зря же написано "... Там теперь characterEncoding=UTF-8 вместо cp1251"

"крайне рекомендуется" не тоджественно "обязательно".
Если разработчики оставили свободу выбора , то ей следует придерживаться до конца.
тем более если в db.opt уже стоит

то зачем дублировать это в patch.sql ?

Более того : в этом файле туча статеметнов "create table" и только в одном месте указывается явно collation
Зачем ??
у меня как раз на том месте апргрейд и сбойнул....

P.S. прелесть от базы в utf8 тоже весьма сомнительна, кроме гемороя при конвертации с помощью alter table. ( Кроме туманных переспектив охватить рынок ACP по всему миру.) Хотя если уж на то и пошло - то сразу надо было рекомендовать utf8mb4, чего мелочиться.

_________________
"Все правые - в резерве!" (c) (translate.google.ru/#en/ru/all%20rigths%20reserved)

ох, был холивар про кодировки, если он, то лучше туда =)

_________________

Код:

  Клиент: вер. 6.2.714 / 25.05.2015 17:27:15
    os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_45
  Сервер: вер. 6.2.881 / 22.05.2015 17:56:55
    os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_45

Помощь по администрированию bgbilling в jabber конференции или Группа в telegram
Стиль программирования - пьяный мастерстер
Разработка мобильных приложений

ok!
Не надо никакого холивара!
Кто спорит ? utf8 так utf8...
Тем более конвертация проще простого :

Но вся изюмина в том что после ТАКОЙ конвертации структура полей конвертнутой базы НЕ СООТВЕТСТВУЕТ структуре полей базы в dump.sql!
Потому, что все типы TEXT и VARCHAR перетекли в MEDIUMTEXT со всеми вытекающими последствиями: отсутствие DEFAULT vlaues и необходимость задания длины индекса.
И как это скажется при следующих обновлениях - никому не известно.

Корректнее было бы к текстовым полям таблиц делать:

Тогда типы полей сохраняются но , количество символов в поле уменьшается в 3 раза ( в худшем случае , во всяком случае mysql при конвертации всегда резервирует 3 , хотя cp1251-символ в
представлении utf8 продолжает храниться в одном байте)

В итоге : конвертнуть базу из cp1251 в utf8 полноценно не получится. А раз так - тогда зачем конвертить ?.
Пусть остаётся в cp1251...
Но patch.sql в upgrade_6.x.zip рушит эту возможность явным заданием во вновь создаваемых таблицах типа сортировки unicode_ci, которая не может быть в cp1251.

_________________
"Все правые - в резерве!" (c) (translate.google.ru/#en/ru/all%20rigths%20reserved)

Менять кодировку или нет - дело, конечно, сугубо индивидуальное. Отвечу просто откуда ноги растут: с 6.1 UTF-8 идёт кодировкой по умолчанию и при разворачивании системы с нуля будет именно она. При снятии дампа с таблиц, имеющих COLLATE utf8_unicode_ci - этот самый COLLATE подставляется АВТОМАТИЧЕСКИ! Вот так он и попал в patch.sql как есть. И еще неизвестно куда и когда попадёт и при каких обновлениях можно поймать грабли, если оставить cp1251.

Мы не заставляем конвертировать в utf8. Как раз для старых клиентов при обновлении можно не конвертировать. Для тех кто ставит с нуля - utf8.
В patch.sql ошибка - исправим, недавно добавили .

исправили.

Вы были правы. На самом деле кодировка единственно правильная для mysql это utf8mb4, с этого времени она рекомендуется, доки и скрипты поправим.

_________________
I'm clever. I've got a computer.

Хм, правильно ли я понял что Вы решили перейти на эту кодировку начиная с BGB 7.2 ?

ЗЫ:
Будте готовы к возможным сокращениям длины PRIMARY KEY в "contract_parameter_type_multilist_item" и UNIQUE KEY в "address_house"

_________________
"Все правые - в резерве!" (c) (translate.google.ru/#en/ru/all%20rigths%20reserved)

Ну вообще 7.1 думали, а что, это критичные изменения? В самом биллинге особо ничего не меняется. Только дамп создания и дефолтный data.properties и вроде всё. Работать будет и с 1251 кому захочется.

Про сокращения длины подробнее поясните.

_________________
I'm clever. I've got a computer.

Нет, 7.1 скорее всего не будем трогать.

ой

_________________
I'm clever. I've got a computer.

увы

_________________
Цитаты великих людей
Напишите в helpdesk © stark
повторяю: => хелпдеск => доработка => профит © dimOn
свершилось... © skn
Мой код изящен, лёгок, оригинален, краток. Как прохладный весенний ветерок, как звонкий ручей! © dimOn
Вежливый разработчик © Artur
Эти баги тоже исправлены, как и те, которые еще не написаны © Artur
ну т.е. существует воркэраунд, ок © dimOn

update_7.1.zip patch.sql


Обновляю 6.2 на 7.1, база в кодировке 1251. Хотя таблица уже есть и поле с такой же кодировкой. кто-то ранее на 6.2 уже обновлял....