Was tun bei einer “Integrity constraint violation”?

Veröffentlicht am 20.09.2011 von jkuensebeck in der Schublade Anderes | Tags: , , | Comments Off

Ihr habt Mist gebaut und die Indexe werden nicht mehr richtig aufgebaut: Beim reindexieren der Indexe “catalog_product_attribute” oder “cataloginventory_stock” landet nur der Fehler
SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '18263-1-1' for key 1'
im Log.
Dann habt ihr wahrscheinlich doppelte Attributewerte in den Produkten, also hat z.B. das Produkt mit der ID 16 für das Attribut “Status” (im Beispiel mit der ID 272) gleich zweimal im selben Store (mit der ID 0) einen Wert gespeichert. In der Datenbank sähe das z.B so aus:

SELECT * FROM catalog_product_entity_int LIMIT 2;
+----------+----------------+--------------+----------+-----------+-------+
| value_id | entity_type_id | attribute_id | store_id | entity_id | value |
+----------+----------------+--------------+----------+-----------+-------+
|        1 |             10 |          272 |        0 |        16 |     0 |
|        2 |             10 |          272 |        0 |        16 |     1 |
+----------+----------------+--------------+----------+-----------+-------+

Das Attribut mit der ID 272 ist also für das Produkt doppelt belegt, einmal mit dem Wert 0 und einmal mit dem Wert 1 (man hat aber auch das selbe Problem, wenn die Werte gleich sind).

Um die problematischen Werte zu finden, helfen folgende SQL Zeilen um Duplikate in den catalog_product_entity_… Tabellen zu finden:

SELECT eav_table.* FROM catalog_product_entity_int AS eav_table GROUP BY entity_id, attribute_id, store_id HAVING COUNT(*) > 1;
SELECT eav_table.* FROM catalog_product_entity_varchar AS eav_table GROUP BY entity_id, attribute_id, store_id HAVING COUNT(*) > 1;
SELECT eav_table.* FROM catalog_product_entity_text AS eav_table GROUP BY entity_id, attribute_id, store_id HAVING COUNT(*) > 1;
SELECT eav_table.* FROM catalog_product_entity_datetime AS eav_table GROUP BY entity_id, attribute_id, store_id HAVING COUNT(*) > 1;
SELECT eav_table.* FROM catalog_product_entity_decimal AS eav_table GROUP BY entity_id, attribute_id, store_id HAVING COUNT(*) > 1;

Um dann die doppelten Werte zu löschen (vorher bitte unbedingt anschauen, was doppelt ist und ob es Widerspüchlichkeiten gibt):

DELETE FROM catalog_product_entity_int WHERE value_id IN (SELECT value_id FROM (SELECT value_id FROM catalog_product_entity_int GROUP BY entity_id, attribute_id, store_id HAVING COUNT(*) > 1) AS temp);
DELETE FROM catalog_product_entity_varchar WHERE value_id IN (SELECT value_id FROM (SELECT value_id FROM catalog_product_entity_varchar GROUP BY entity_id, attribute_id, store_id HAVING COUNT(*) > 1) AS temp);
DELETE FROM catalog_product_entity_text WHERE value_id IN (SELECT value_id FROM (SELECT value_id FROM catalog_product_entity_text GROUP BY entity_id, attribute_id, store_id HAVING COUNT(*) > 1) AS temp);
DELETE FROM catalog_product_entity_datetime WHERE value_id IN (SELECT value_id FROM (SELECT value_id FROM catalog_product_entity_datetime GROUP BY entity_id, attribute_id, store_id HAVING COUNT(*) > 1) AS temp);
DELETE FROM catalog_product_entity_decimal WHERE value_id IN (SELECT value_id FROM (SELECT value_id FROM catalog_product_entity_decimal GROUP BY entity_id, attribute_id, store_id HAVING COUNT(*) > 1) AS temp);

Die eigentliche Frage ist, wie man überhaupt zu so einer EAV-Struktur kommen konnte. Das kann eigentlich nicht passieren, denn es gibt einen Unique-Index über die Felder (attribute_id, entity_id, store_id). Per SQL kann man diese aber über mit “SET  UNIQUE_CHECKS=0″ umgehen, was zum Beispiel am Anfang eines phpMyAdminDumps immer gemacht wird. Der “Trick” wird auch von eingen Extensions benutzt, um schneller in die Datenbank zu schreiben.


Keine Kommentare mehr möglich, sorry.