Форумы / National / Russian / Тех. поддержка / [Решено] Обновление - Fatal error

#46321 Alex300:

Я пытаюсь еще раз продебажить инсталлер. Дело не в патче и не в версионности. Но пока не знаю в чем.

Кажется начинаю догадыватся в чем причина. Смотри, когда на сайте установлена версия 0.9.22 и структура у базы от этой 22-ой версии и тут зачем то накатывают файлы мастер ветки (хотя мастер ветка никогда не предназначалась для установки на рабочие сайты, для этого и создаются релизы) и еще и запускают скрипт инсталятор\обновлятор. Скрипт смотри в файл и питается совершить обновление до этой версии. Тоесть пытается применить патч 0.9.22 но поскольку сайт и структура базы и так уже от версии 22 то и получаем на выходе ошибки типа:

Fatal error

2023-03-27 02:27

SQL error 42S21: Column already exists: 1060 Duplicate column name 'log_uid'

#0  cot_diefatal(SQL error 42S21: Column already exists: 1060 Duplicate column name 'log_uid') called at [/var/www/cotontisite.com/system/database.php:368]
#1  CotDB->query(ALTER TABLE `cot_logger` ADD `log_uid` int UNSIGNED NOT NULL DEFAULT '0') called at [/var/www/cotontisite.com/system/database.php:780]
#2  CotDB->runScript(
INSERT INTO `cot_config` (`config_owner`, `config_cat`, `config_order`, `config_name`, `config_type`, `config_value`, `config_default`, `config_variants`, `config_text`) VALUES
('core','main','08','loggerlevel',2,'sec+adm+ext','sec+adm+ext','none,sec,adm,ext,sec+adm,sec+ext,adm+ext,sec+adm+ext,all','');

ALTER TABLE `cot_logger` MODIFY `log_group` varchar(64) DEFAULT 'adm';
ALTER TABLE `cot_logger` ADD `log_uid` int UNSIGNED NOT NULL DEFAULT '0';
ALTER TABLE `cot_logger` ADD `log_type` varchar(32) DEFAULT '';
ALTER TABLE `cot_logger` ADD `log_status` varchar(24) DEFAULT '';
ALTER TABLE `cot_logger` ADD `log_uri` varchar(255) DEFAULT '';

UPDATE `cot_logger` SET `log_group` = 'forums' WHERE `log_group` = 'for';
UPDATE `cot_logger` SET `log_group` = 'users' WHERE `log_group` = 'usr';
UPDATE `cot_logger` SET `log_group` = 'page' WHERE `log_group` = 'pag';) called at [/var/www/cotontisite.com/system/extensions.php:85]
#3  cot_apply_patches(./setup/siena, 0.9.22) called at [/var/www/cotontisite.com/modules/install/inc/install.update.php:245]
#4  include(/var/www/cotontisite.com/modules/install/inc/install.update.php) called at [/var/www/cotontisite.com/install.php:149]

Потому что патч 22 который уже ранее добавил колонку log_uid снова при повторной попытке её добавить вызовет ошибку.

Выходит ты зря (в разрезе текущей ситуации) делал проверку двойного запуска за промежуток времени. В целом этот функционал полезен но сейчас он ситуацию не исправляет.

Идём далее - поскольку инсталятор пытается обновится до 22 версии то и патч 23 он не запускает, а значит на выходе имеем сайт который работает на файлах от будущей 23 версии которым требуются новые колонки в таблицах но патч для перехода к 23 версии не отработал и новые колонки не добавил в базу, а потому и множетсвенные ошибки при работе такой промежуточной версии ядра. Потому неважно с чем бы подобные изменения были связаны (переработка системы протоколирования или что либо другое) итог будет один - криво работающий сайт.

Итого тезисно:

• Как решение сейчас достаточно просто было загодя обновить версию в ядре.
• На дальнейшее для себя команде запомнить правило - при первом же комите после релиза обновлять  эту строку. Это не предотвратит совсем ошибок подобного рода но для одиночного перехода от предыдущей релизной версии до мастер ветки (для тестеров) часть проблем уберёт. Повторные попытки обновляться между разными состояними мастер ветки все равно могут вызывать такие ситуации.
• Еще где то написать предупреждение для пользователей "Если используете мастер ветку то делаете это на свой страх и риск, поскольку она не предназначена для установки на рабочии сайты, для этого выпускаются релизные версии, ибо инсталятор умеет обновлятся только от версии к версии.". Правда и не знаю где его разместить 
• На будуще запланировать задачу доработать инсталятор что б он умел обрабатывать такие исключения, правда слабо представляется простая реализация такой проверки исключений, причем ради нештатных ситуаций которые не должны происходить с простыми пользователями.

Добавлено 9 минут спустя:

Это опять на уровне догадки на базе всех сообщений об ошибках при использовании текущего когда из репозитория, требует проверки, но версия как мне кажется, очень даже правдоподобная

Добавлено 35 минут спустя:

Перечитал соседние топики с упоминанием такой же проблемы и понял что в тексте выше немного напутал с именами полей - где то шибка из-за log_uri а где то из-за log_uid. Но по сути версия о том в чем причина бага остаётся не изменной.