upgrade 6.0 to 6.2 (CRM:CLOSED)

Основная часть программы и общие вопросы по модулям. Установка и настройка BGBillingServer, BGBillingClient.

upgrade 6.0 to 6.2

Сообщение ok-2004 » 19 июл 2016, 18:21

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

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

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

$this->bbcode_second_pass_code('', '
CREATE TABLE `contract_payment_deleted`
.....
comment` varchar(200) COLLATE utf8_unicode_ci
.....
')

Как-то странно для cp1251 иметь такую collate , не ?
"Все правые - в резерве!" (c) (translate.google.ru/#en/ru/all%20rigths%20reserved)
ok-2004
Клиент
 
Сообщения: 599
Зарегистрирован: 21 май 2008, 10:54
Откуда: 50-й рег.

Re: upgrade 6.0 to 6.2

Сообщение barguzin2 » 19 июл 2016, 18:32

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

Re: upgrade 6.0 to 6.2

Сообщение ok-2004 » 19 июл 2016, 20:08

"крайне рекомендуется" не тоджественно "обязательно".
Если разработчики оставили свободу выбора , то ей следует придерживаться до конца.
тем более если в db.opt уже стоит
$this->bbcode_second_pass_code('', '
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)
ok-2004
Клиент
 
Сообщения: 599
Зарегистрирован: 21 май 2008, 10:54
Откуда: 50-й рег.

Re: upgrade 6.0 to 6.2

Сообщение skyb » 19 июл 2016, 21:01

ох, был холивар про кодировки, если он, то лучше туда =)
$this->bbcode_second_pass_code('', '
Клиент: вер. 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
Стиль программирования - пьяный мастерстер
Разработка мобильных приложений
Аватара пользователя
skyb
Клиент
 
Сообщения: 7166
Зарегистрирован: 03 авг 2009, 18:42
Откуда: Благовещенск

Re: upgrade 6.0 to 6.2

Сообщение ok-2004 » 20 июл 2016, 01:24

ok!
Не надо никакого холивара!
Кто спорит ? utf8 так utf8...
Тем более конвертация проще простого :
$this->bbcode_second_pass_code('', '
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 и необходимость задания длины индекса.
И как это скажется при следующих обновлениях - никому не известно.

Корректнее было бы к текстовым полям таблиц делать:
$this->bbcode_second_pass_code('', '
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)
ok-2004
Клиент
 
Сообщения: 599
Зарегистрирован: 21 май 2008, 10:54
Откуда: 50-й рег.

Re: upgrade 6.0 to 6.2

Сообщение barguzin2 » 20 июл 2016, 08:25

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

Re: upgrade 6.0 to 6.2

Сообщение stark » 22 июл 2016, 19:54

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

Re: upgrade 6.0 to 6.2 (CRM)

Сообщение stark » 25 июл 2016, 15:09

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

Re: upgrade 6.0 to 6.2

Сообщение dimOn » 20 ноя 2017, 20:06

$this->bbcode_second_pass_quote('ok-2004', ' ')Хотя если уж на то и пошло - то сразу надо было рекомендовать utf8mb4, чего мелочиться.

Вы были правы. На самом деле кодировка единственно правильная для mysql это utf8mb4, с этого времени она рекомендуется, доки и скрипты поправим.
dimOn
 
Сообщения: 5918
Зарегистрирован: 30 май 2008, 15:51

Re: upgrade 6.0 to 6.2 (CRM)

Сообщение ok-2004 » 20 ноя 2017, 20:30

$this->bbcode_second_pass_code('', '
с этого времени она рекомендуется, доки и скрипты поправим.
')
Хм, правильно ли я понял что Вы решили перейти на эту кодировку начиная с BGB 7.2 ?

ЗЫ:
Будте готовы к возможным сокращениям длины PRIMARY KEY в "contract_parameter_type_multilist_item" и UNIQUE KEY в "address_house"
"Все правые - в резерве!" (c) (translate.google.ru/#en/ru/all%20rigths%20reserved)
ok-2004
Клиент
 
Сообщения: 599
Зарегистрирован: 21 май 2008, 10:54
Откуда: 50-й рег.

Re: upgrade 6.0 to 6.2 (CRM)

Сообщение dimOn » 20 ноя 2017, 21:05

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

Про сокращения длины подробнее поясните.
dimOn
 
Сообщения: 5918
Зарегистрирован: 30 май 2008, 15:51

Re: upgrade 6.0 to 6.2 (CRM)

Сообщение stark » 21 ноя 2017, 13:02

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

Re: upgrade 6.0 to 6.2 (CRM)

Сообщение dimOn » 21 ноя 2017, 13:08

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

Re: upgrade 6.0 to 6.2 (CRM)

Сообщение Phricker » 21 ноя 2017, 13:13

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

Re: upgrade 6.0 to 6.2

Сообщение barguzin2 » 16 апр 2019, 16:15

$this->bbcode_second_pass_quote('stark', '')ы не заставляем конвертировать в utf8. Как раз для старых клиентов при обновлении можно не конвертировать. Для тех кто ставит с нуля - utf8.
В patch.sql ошибка - исправим, недавно добавили .

$this->bbcode_second_pass_quote('stark', '')справили.


update_7.1.zip patch.sql
$this->bbcode_second_pass_quote('', '
') 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 уже обновлял....
barguzin2
Клиент
 
Сообщения: 1080
Зарегистрирован: 09 фев 2011, 15:28
Вернуться к началу


Вернуться в Ядро системы

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

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 1