Unikalne naruszenie ograniczeń w uaktualnieniu Magento 1.4.0 do 1.6.2.0

Question

Uaktualniam istniejącą witrynę Magento. Po około 10 minutach, Magento zgłasza wyjątek, a kiedy sprawdzić plik raportu o błędzie w/var/raport widzę następujący komunikat o błędzie i stosu zrzutu:

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";} 

Ogólna rada gdzie indziej w Internecie jest do zmiany <initStatements> w app/etc/config.xml czytać:

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

jednak uszkodzenia bazy danych systemu integralność ograniczeniem jest gwarantowana droga do niezwykle trudne do obsługi i rozwiązywania problemów później. Jest to hack, który sprawia, że ​​skrypt aktualizacji nie ulega awarii z powodu błędu, w rzeczywistości NIE naprawia problemu w żaden sposób w kształcie lub formie.

Czy społeczność StackOverflow może pomóc w znalezieniu lepszego rozwiązania lub dobrym wyjaśnieniem, dlaczego wyłączenie sprawdzania integralności w MySQL jest dobrym pomysłem?

Answer 1

Ta tabela służy do obcięcia. http://docs.nexcess.net/magento-database-maintenance

Jest to jedna z kilku tabel zbierających informacje o użytkowaniu strony, które nie są krytyczne dla działania magento. (. To ma wpływu na raporty z klientami, jeśli używasz tych)

Problem polega na tym ze skryptem migracji z:

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

Jego zmieniając kolumnę, która używana do domyślnych NULL domyślne do not null.

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

Błąd pochodzi z unikalnego indeksu dla tej kolumny. Null był wcześniejszy, więc MySQL ignorował unikalny indeks. Po ustawieniu wartości domyślnej na null wartość NULL nie jest już poprawną wartością i próbuje ustawić wartość kolumny na 0. Przechodzi do drugiego wiersza, a teraz łamie unikalny indeks i pojawia się błąd, http://bugs.mysql.com/bug.php?id=8173

Kod 1.4x zapisał dane w tej tabeli, które nie są zgodne z nowym schematem. Będzie to również bardzo trudne do oczyszczenia, ponieważ brakujące informacje potrzebne do spełnienia unikalnego indeksu. Najszybszą opcją jest po prostu obcięcie tabeli.

Answer 2

Jest to stosunkowo łatwe do odczytania z komunikatu o błędzie. Masz zduplikowanego klienta (lub więcej niż jednego zduplikowanego klienta).

Otwórz tabelę customer_entity w phpMyadmin i poszukaj duplikatów. W zależności od tego, ilu masz klientów, możesz chcieć przejść przez to ręcznie, jest szansa, że ​​duplikaty będą pochodzić z twoich testów z wiadomościami w stylu "fred@test.com". Powinieneś być w stanie bezpiecznie usunąć te, gdy przejdziesz przez stół i opracował dla siebie, co się stało.