der Update auf 6.4 ist leider bei der Datenbank-Migration hängengeblieben mit dem untenstehenden Fehler, wir hatten die 6.3.5.4 mit PHP 7.4.18 und 10.3.29-MariaDB und der Professional Edition.
Habe den Fehler hier im Forum bisher nicht gesehen oder hatte den auch jemand gehabt?
Received the following error message:
An exception occurred while executing ‚ALTER TABLE product_translation ADD COLUMN slot_config JSON AFTER custom_fields, ADD CONSTRAINT json.product_translation.slot_config CHECK (JSON_VALID(slot_config))‘: SQLSTATE[42S22]: Column not found: 1054 Unknown column ‚....product.translation.custom_fields‘ in ‚CHECK‘
Please try to fix this error and restart the update.
Response
{„valid“:false,„errorMsg“:„An exception occurred while executing ‚ALTER TABLE product_translation\n ADD COLUMN slot_config JSON AFTER custom_fields,\n ADD CONSTRAINT json.product_translation.slot_config CHECK (JSON_VALID(slot_config))‘:\n\nSQLSTATE[42S22]: Column not found: 1054 Unknown column ‚....product.translation.custom_fields‘ in ‚CHECK‘“}
Okay, beim Recovery-Befehl ausführen, hat es jetzt erstaunlicherweise funktioniert, keine Ahnung warum nicht gleich beim ersten Mal, wir sind jetzt bei Shopware 6.4
Das Problem war diese Migration: https://github.com/shopware/platform/blob/trunk/src/Core/Migration/V6_4/Migration1610337444AddSlotConfigToProductTranslationTable.php
Der SQL-Befehl in der Migration hat auch funktioniert, wenn man den von Hand z.B. in DBeaver ausgeführt hat, hab den dann wieder rückgängig gemacht und den Recovery gestartet. Warum das nicht beim ersten Mal funktioniert hat ist mir schleierhaft.
@schnere Okay, stimmt, habe ich jetzt auch gesehen: „MariaDB 10.3.29, 10.4.19, 10.5.10 are not compatible at the moment“. Frag mich nur, warum www.dogado.de uns diese DB-Version installiert hat, wenn die doch wissen sollten, daß das nicht kompatibel ist.
Mehr Info von Shopware wäre auch toll, also was denn nun nicht kompatibel ist, soviel kann es ja nicht sein, kann mir beim besten Willen nicht vorstellen, daß von 10.3.22 auf 10.3.29 so ein großer Unterschied bei MariaDB ist, okay, außer die haben in 10.3.29 ein total blöden Bug eingebaut. Und eine Info, ob das dann in naher Zukunft kompatibel gemacht wird, wäre auch nicht schlecht.
Wir sind aber weiterhin mit 10.3.29 unterwegs, der SQL-Befehl in der Migration hat ja letztendlich wie oben beschrieben funktioniert und was anderes ist uns bisher nicht aufgefallen.
Hallo , ich habe auch den Fehler - bekomme es aber nicht gelöst. Muss diese Spalte gelöscht werden ? Wenn ja auch das funktionniert nicht. Bräuchte hier Hilfe wie ich da weiter komme.
Danke schön
Error
Received the following error message:
An exception occurred while executing ‚ALTER TABLE product_translation ADD COLUMN slot_config JSON AFTER custom_fields, ADD CONSTRAINT json.product_translation.slot_config CHECK (JSON_VALID(slot_config))‘: SQLSTATE[42S22]: Column not found: 1054 Unknown column ‚kmpracing_shopware62021.product.translation.custom_fields‘ in ‚CHECK‘
Please try to fix this error and restart the update.
Response
{„valid“:false,„errorMsg“:„An exception occurred while executing ‚ALTER TABLE product_translation\n ADD COLUMN slot_config JSON AFTER custom_fields,\n ADD CONSTRAINT json.product_translation.slot_config CHECK (JSON_VALID(slot_config))‘:\n\nSQLSTATE[42S22]: Column not found: 1054 Unknown column ‚kmpracing_shopware62021.product.translation.custom_fields‘ in ‚CHECK‘“}
Bei mir leider nicht - gerade versucht
Läuft auf den gleichen Fehler:
Error
Received the following error message:
An exception occurred while executing ‚ALTER TABLE product_translation ADD COLUMN slot_config JSON AFTER custom_fields, ADD CONSTRAINT json.product_translation.slot_config CHECK (JSON_VALID(slot_config))‘: SQLSTATE[42S22]: Column not found: 1054 Unknown column ‚kmpracing_shopware62021.product.translation.custom_fields‘ in ‚CHECK‘
Please try to fix this error and restart the update.
Response
{„valid“:false,„errorMsg“:„An exception occurred while executing ‚ALTER TABLE product_translation\n ADD COLUMN slot_config JSON AFTER custom_fields,\n ADD CONSTRAINT json.product_translation.slot_config CHECK (JSON_VALID(slot_config))‘:\n\nSQLSTATE[42S22]: Column not found: 1054 Unknown column ‚kmpracing_shopware62021.product.translation.custom_fields‘ in ‚CHECK‘“}
Oh, tut mir leid.
Ich hatte den Befehl der Migration ja per Hand in der DB mal ausgeführt, der hatte an sich funktioniert,
die column hatte ich dann wieder gelöscht und den recovery-Befehl ausgeführt.
Ansonsten kann ich Dir leider auch nicht weiterhelfen, du hast auch die MariaDB 10.3.29?
Also bei mir hat der Befehl manuell tatsächlich auch nicht funktioniert - gleicher Fehler.
Das Downgrade hat jedenfalls problemlos funktioniert und das ist für mich die praktikabelste Lösung.
Eine Alternative wäre den Patch zu cherry-picken (was üblicherweise nicht ganz so einfach ist) oder eben auf eine gepatchte Version zu warten.
kannst du bitte noch mal genau erklären wie du das gemacht hast. Für Anfänger
„Ich hatte den Befehl der Migration ja per Hand in der DB mal ausgeführt, der hatte an sich funktioniert,
die column hatte ich dann wieder gelöscht und den recovery-Befehl ausgeführt.“
Falls euer Hoster nicht auf eine ältere MariaDB Version zurück kann oder möchte, gibt es noch die Möglichkeit vor dem Update ein „FLUSH TABLES;“ auszuführen. Das umgeht den Fehler während des Updates. Inwieweit das bei euch auf einem Webpaket angewendet werden kann, sollte euch aber euer Hoster sagen können.
Zum Thema Dogado, da springe ich mal mit ein. In MariaDB gibt es einen Bug. Dieser betrifft die MariaDB Versionen 10.3.29, 10.4.19 und 10.5.10. Meistens werden diese Updates automatisch eingespielt. Ich denke dass die Kollegen vorher nicht wissen konnten, dass es mit der aktuellen MariaDB Version und Shopware 6 zu Problemen kommen könnte. Offensichtlich tritt der Bug auch nicht permanent auf, was die Fehleranalyse erschwert.
Da das Update von Shopware auch früher raus kam als die neue MariaDB Version, gehe ich auch mal davon aus, dass die System-Anforderungen von Shopware nachträglich angepasst wurden.
Hallo,
an sich habe ich einfach den „Alter Table…“ aus der Migration (s. oben) einfach perHand in phpMyAdmin ausgeführt, dann die Spalte wieder gelöscht und die update/recovery-Seite aufgerufen. Aber so wie es aussieht, hat das wohl nur zufällig bei uns funktioniert.
Denke, der Hinweis von enerSpace ist der richtigere.
Danke für die hilfreichen Hinweise, insbesondere der Hinweis mit bzgl. „FLUSH TABLES“ hat geholfen. Da uns die Rechte dazu fehlten, haben wir beim Provider angerufen, welcher den Befehl in der MariaDB 10.5.10 für uns ausführen konnte.
Wir hatten danach noch Probleme den „Wartungs-Modus“ auszuschlaten. Letztlich hat es mit den erneuten Aufruf von /recovery/update/index.php/cleanup funktioniert.
