Уникальное нарушение ограничений при обновлении Magento 1.4.0 до 1.6.2.0

Я запускаю обновление на существующем сайте Magento. Примерно через 10 минут Magento сообщает об исключении, и когда я проверяю файл отчета об ошибке в /var/report, я вижу следующее сообщение об ошибке и дамп пакета:

a:5:{i:0;s:223:"Error in file: "/var/www/vhosts/mymagesite/app/code/core/Mage/Customer/sql/customer_setup/mysql4-upgrade-1.5.9.9-1.6.0.0.php" - SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '0-8' for key 'UNQ_BY_CUSTOMER'";i:1;s:952:"#0 /var/www/vhosts/mymagesite/app/code/core/Mage/Core/Model/Resource/Setup.php(645): Mage::exception('Mage_Core', 'Error in file: ...')
#1 /var/www/vhosts/mymagesite/app/code/core/Mage/Core/Model/Resource/Setup.php(437): Mage_Core_Model_Resource_Setup->_modifyResourceDb('upgrade', '1.4.0.0.7', '1.6.1.0')
#2 /var/www/vhosts/mymagesite/app/code/core/Mage/Core/Model/Resource/Setup.php(320): Mage_Core_Model_Resource_Setup->_upgradeResourceDb('1.4.0.0.7', '1.6.1.0')
#3 /var/www/vhosts/mymagesite/app/code/core/Mage/Core/Model/Resource/Setup.php(235): Mage_Core_Model_Resource_Setup->applyUpdates()
#4 /var/www/vhosts/mymagesite/app/code/core/Mage/Core/Model/App.php(412): Mage_Core_Model_Resource_Setup::applyAllUpdates()
#5 /var/www/vhosts/mymagesite/app/code/core/Mage/Core/Model/App.php(338): Mage_Core_Model_App->_initModules()
#6 /var/www/vhosts/mymagesite/app/Mage.php(640): Mage_Core_Model_App->run(Array)
#7 /var/www/vhosts/mymagesite/index.php(80): Mage::run('default', 'store')
#8 {main}";s:3:"url";s:16:"/index.php/admin";s:11:"script_name";s:10:"/index.php";s:4:"skin";s:7:"default";}

Общие рекомендации в другом месте в Интернете - изменить <initStatements> в app/etc/config.xml следующим образом:

<initStatements>SET NAMES utf8; SET FOREIGN_KEY_CHECKS=0; SET UNIQUE_CHECKS=0;</initStatements>

Однако отключение системы ограничения целостности баз данных - это гарантированный путь к невероятно сложной поддержке и устранению неполадок позже. Это взлом, который делает обновление script не аварийным с ошибкой, оно НЕ на самом деле не исправляет проблему в какой-либо форме или форме.

Может ли сообщество StackOverflow помочь либо с лучшим решением, либо с хорошим объяснением того, почему отличная проверка целостности в MySQL - хорошая идея?

Ответ 1

Эта таблица одобрена для усечения. http://docs.nexcess.net/magento-database-maintenance

Его одна из нескольких таблиц, собирающая информацию об использовании сайта, которая не имеет решающего значения для работы magento. (Это влияет на отчеты клиентов, если вы их используете.)

Проблема заключается в миграции script из:

/app/code/core/Mage/Customer/sql/customer_setup/mysql4-upgrade-1.5.9.9-1.6.0.0.php

Его изменение столбца, для которого по умолчанию используется значение NULL, по умолчанию не равно null.

ALTER TABLE `report_compared_product_index` MODIFY COLUMN `customer_id` int UNSIGNED NOT NULL COMMENT ''

Ошибка указана из уникального индекса в этом столбце. Он был пустым, поэтому MySQL игнорировал уникальный индекс. Как только значение по умолчанию было равно null, значение NULL больше не является допустимым значением и пытается установить значение столбца равным 0. Оно попадает во вторую строку и теперь разбивает уникальный индекс и вы получаете ошибку, http://bugs.mysql.com/bug.php?id=8173

1.4x код сохраненных данных в этой таблице, который несовместим с новой схемой. Его также будет довольно сложно очистить, потому что ваша недостающая информация необходима для удовлетворения уникального индекса. Самый быстрый вариант - просто обрезать таблицу.

Ответ 2

Это относительно легко расшифровать из сообщения об ошибке. У вас есть дубликат клиента (или нескольких дубликатов клиентов).

Откройте таблицу customer_entity в phpMyadmin и найдите дубликаты. В зависимости от того, сколько у вас клиентов вы, возможно, захотите пройти через это вручную, есть вероятность, что дубликаты будут от вашего собственного тестирования с помощью электронных писем '[email protected]'. Вы должны быть в состоянии безопасно удалить их, как только вы прошли через таблицу, и разработали для себя, что произошло.