BiTel

Форум BiTel
bgbilling.ru     docs.bitel.ru     wiki.bitel.ru     dbinfo.bitel.ru     bgcrm.ru     billing.bitel.ru     bitel.ru    
Текущее время: 28 мар 2024, 20:13

Часовой пояс: UTC + 5 часов [ Летнее время ]




Начать новую тему Ответить на тему  [ Сообщений: 15 ] 
Автор Сообщение
 Заголовок сообщения: upgrade 6.0 to 6.2
СообщениеДобавлено: 19 июл 2016, 18:21 
Не в сети
Клиент

Зарегистрирован: 21 май 2008, 10:54
Сообщения: 599
Откуда: 50-й рег.
Карма: 40
Доброе время суток!
Решил тут попробовать сабж.
Встретил одну непонятку...
моя база в cp1251.

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

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

Код:
CREATE TABLE `contract_payment_deleted`
.....
comment` varchar(200) COLLATE utf8_unicode_ci
.....


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

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: upgrade 6.0 to 6.2
СообщениеДобавлено: 19 июл 2016, 18:32 
Не в сети
Клиент

Зарегистрирован: 09 фев 2011, 15:28
Сообщения: 1092
Карма: 135
Не, просто крайне рекомендуется перевести базу в UTF-8. Ну и не зря же написано "... Там теперь characterEncoding=UTF-8 вместо cp1251"


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: upgrade 6.0 to 6.2
СообщениеДобавлено: 19 июл 2016, 20:08 
Не в сети
Клиент

Зарегистрирован: 21 май 2008, 10:54
Сообщения: 599
Откуда: 50-й рег.
Карма: 40
"крайне рекомендуется" не тоджественно "обязательно".
Если разработчики оставили свободу выбора , то ей следует придерживаться до конца.
тем более если в db.opt уже стоит
Код:
default-character-set=utf8
default-collation=utf8_unicode_ci

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

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

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

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: upgrade 6.0 to 6.2
СообщениеДобавлено: 19 июл 2016, 21:01 
Не в сети
Клиент
Аватара пользователя

Зарегистрирован: 03 авг 2009, 18:42
Сообщения: 7166
Откуда: Благовещенск
Карма: 241
ох, был холивар про кодировки, если он, то лучше туда =)

_________________
Код:
  Клиент: вер. 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
Стиль программирования - пьяный мастерстер
Разработка мобильных приложений


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: upgrade 6.0 to 6.2
СообщениеДобавлено: 20 июл 2016, 01:24 
Не в сети
Клиент

Зарегистрирован: 21 май 2008, 10:54
Сообщения: 599
Откуда: 50-й рег.
Карма: 40
ok!
Не надо никакого холивара!
Кто спорит ? utf8 так utf8...
Тем более конвертация проще простого :
Код:
alter table CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci + alter database bgbilling DEFAULT CHARACTER SET = utf8 DEFAULT COLLATE = utf8_unicode_ci

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

Корректнее было бы к текстовым полям таблиц делать:
Код:
ALTER TABLE  MODIFY text_column CHARACTER SET utf8 + ALTER TABLE DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci.

Тогда типы полей сохраняются но , количество символов в поле уменьшается в 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)


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: upgrade 6.0 to 6.2
СообщениеДобавлено: 20 июл 2016, 08:25 
Не в сети
Клиент

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: upgrade 6.0 to 6.2
СообщениеДобавлено: 22 июл 2016, 19:54 
Не в сети
Разработчик

Зарегистрирован: 08 ноя 2007, 01:05
Сообщения: 8343
Откуда: Уфа
Карма: 238
Мы не заставляем конвертировать в utf8. Как раз для старых клиентов при обновлении можно не конвертировать. Для тех кто ставит с нуля - utf8.
В patch.sql ошибка - исправим, недавно добавили .


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: upgrade 6.0 to 6.2 (CRM)
СообщениеДобавлено: 25 июл 2016, 15:09 
Не в сети
Разработчик

Зарегистрирован: 08 ноя 2007, 01:05
Сообщения: 8343
Откуда: Уфа
Карма: 238
исправили.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: upgrade 6.0 to 6.2
СообщениеДобавлено: 20 ноя 2017, 20:06 
Не в сети
Аватара пользователя

Зарегистрирован: 30 май 2008, 15:51
Сообщения: 6055
Карма: 244
ok-2004 писал(а):
Хотя если уж на то и пошло - то сразу надо было рекомендовать utf8mb4, чего мелочиться.

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

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: upgrade 6.0 to 6.2 (CRM)
СообщениеДобавлено: 20 ноя 2017, 20:30 
Не в сети
Клиент

Зарегистрирован: 21 май 2008, 10:54
Сообщения: 599
Откуда: 50-й рег.
Карма: 40
Код:
с этого времени она рекомендуется, доки и скрипты поправим.

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

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

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: upgrade 6.0 to 6.2 (CRM)
СообщениеДобавлено: 20 ноя 2017, 21:05 
Не в сети
Аватара пользователя

Зарегистрирован: 30 май 2008, 15:51
Сообщения: 6055
Карма: 244
Ну вообще 7.1 думали, а что, это критичные изменения? В самом биллинге особо ничего не меняется. Только дамп создания и дефолтный data.properties и вроде всё. Работать будет и с 1251 кому захочется.

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

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: upgrade 6.0 to 6.2 (CRM)
СообщениеДобавлено: 21 ноя 2017, 13:02 
Не в сети
Разработчик

Зарегистрирован: 08 ноя 2007, 01:05
Сообщения: 8343
Откуда: Уфа
Карма: 238
Нет, 7.1 скорее всего не будем трогать.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: upgrade 6.0 to 6.2 (CRM)
СообщениеДобавлено: 21 ноя 2017, 13:08 
Не в сети
Аватара пользователя

Зарегистрирован: 30 май 2008, 15:51
Сообщения: 6055
Карма: 244
ой

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: upgrade 6.0 to 6.2 (CRM)
СообщениеДобавлено: 21 ноя 2017, 13:13 
Не в сети
Клиент
Аватара пользователя

Зарегистрирован: 29 мар 2010, 23:11
Сообщения: 5854
Карма: 472
увы

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: upgrade 6.0 to 6.2
СообщениеДобавлено: 16 апр 2019, 16:15 
Не в сети
Клиент

Зарегистрирован: 09 фев 2011, 15:28
Сообщения: 1092
Карма: 135
stark писал(а):
Мы не заставляем конвертировать в utf8. Как раз для старых клиентов при обновлении можно не конвертировать. Для тех кто ставит с нуля - utf8.
В patch.sql ошибка - исправим, недавно добавили .

stark писал(а):
исправили.


update_7.1.zip patch.sql
Цитата:
CREATE TABLE `contract_payment_deleted` (
`id` int(11) NOT NULL DEFAULT '0',
`dt` date NOT NULL DEFAULT '0000-00-00',
`cid` int(10) unsigned NOT NULL DEFAULT '0',
`pt` int(10) unsigned NOT NULL DEFAULT '0',
`uid` int(11) NOT NULL DEFAULT '0',
`summa` decimal(10,2) NOT NULL,
`comment` varchar(200) COLLATE utf8_unicode_ci NOT NULL DEFAULT '',
`lm` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
`time_change` timestamp NOT NULL DEFAULT '0000-00-00 00:00:00',
PRIMARY KEY (`id`),
KEY `pt_dt` (`pt`,`dt`),
KEY `dt_cid` (`dt`,`cid`),
KEY `uid` (`uid`),
KEY `cid_dt` (`cid`,`dt`)
);


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


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 15 ] 

Часовой пояс: UTC + 5 часов [ Летнее время ]


Кто сейчас на конференции

Сейчас этот форум просматривают: Google [Bot] и гости: 1


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  
cron
POWERED_BY
Русская поддержка phpBB
[ Time : 0.089s | 50 Queries | GZIP : On ]