Das stimmt, wenn man erst in den Fehler laufen muss um Ihn zu fixen, ist das etwas ungünstig. Besser/sauberer wäre es gewesen, wenn man auch von 6.3.x.x auf das 6.4.1.0 updaten könnte.
Was heißt „besser“? Es löst das Problem nicht. Ein einzelner Fix für die Datenbank wäre sinnvoll gewesen.
Da muss ich widersprechen, wenn der Fix, der nun in der 6.4.1.0 verfügbar ist, direkt von 6.3.x.x implementierbar wäre, würde es das Problem lösen, denn das Problem trat ja gemäß Thread Titel beim Update auf 6.4.0.0 auf.
Also wenn Installationen die auf 6.3.x.x sind direkt das update auf 6.4.1.0 angeboten werden würde würde man das Problem von 6.4.0.0 umgehen, indem man es im gleichen Zuge fixt da 6.4.1.0 installiert wird welche alle Änderungen von 6.4.0.0 und die von 6.4.1.0 beinhaltet.
Ja das ist mir schon klar, so wie von dir beschrieben würde es funktionieren. Aber jetzt ist der Fix nicht brauchbar.
Hallo,
ich verstehe die Logik hinter dieser Fix nicht. Wenn die Aktualisierung auf 6.4.0.0 fehlschlägt, aber die Version 6.4.1 die Version 6.4.0 als Basis braucht, wie kann ich das dann nutzen? Dank und Gruß
Auf die 6.4.1.0 kannst du normal Updates ohne vorher die 6.4.0.0 zu installieren
Hallo Moritz,
warum steht dann im Changelog der Shopware Version 6.4.1.0 ( Shopware Changelog Shopware 6 ):„ Als Voraussetzung wird mindestens Shopware 6.4.0.0 oder größer benötigt“?
Grüße
Sebastian
Prüfe ich morgen nochmal.
Konntest Du das intern schon prüfen @Moritz_Naczenski?
Für Dein Feedback bedanke ich mich im Voraus.
Gruss
Mando
Hallo liebe Community,
wir haben heute morgen die Min-Version für das 6.4.1.0 Update, welches den Fix für die Migration enthält, auf 6.3 reduziert, so dass ein direktes Update von einer 6.3.x möglich ist. Bitte bedenkt, dass in diesem Fall keine Kompatibilität für ein Blue-Green Deployment gewährleistet werden kann.
Sollte es weiterhin zu Problemen kommen, schreibt gerne hier im Thread.
Sonnige Grüße,
Phil
1 „Gefällt mir“
Hallo Philipp,
danke für dein Feedback. Bedeutet das, dass eine Aktualisierung von 6.3.5.4 auf 6.4.1 auch die Änderungen beinhaltet, die in der Version 6.4.0 dabei waren?
Und was bedeutet das:
keine Kompatibilität für ein Blue-Green Deployment gewährleistet werden kann.
Danke und Gruß,
Bei mir wirft das Update von 6.3.5.1 auf 6.4.1.0 immer noch einen Fehler:
Error
Received the following error message:
An exception occurred while executing ' CREATE TABLE `currency_country_rounding` ( `id` binary(16) NOT NULL, `currency_id` binary(16) NOT NULL, `country_id` binary(16) NOT NULL, `item_rounding` json NOT NULL, `total_rounding` json NOT NULL, `created_at` datetime(3) NOT NULL, `updated_at` datetime(3) NULL, PRIMARY KEY (`id`), KEY `currency_id` (`currency_id`), KEY `country_id` (`country_id`), CONSTRAINT `currency_country_rounding_ibfk_2` FOREIGN KEY (`currency_id`) REFERENCES `currency` (`id`) ON DELETE CASCADE ON UPDATE CASCADE, CONSTRAINT `currency_country_rounding_ibfk_3` FOREIGN KEY (`country_id`) REFERENCES `country` (`id`) ON DELETE CASCADE ON UPDATE CASCADE ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci ': SQLSTATE[42S01]: Base table or view already exists: 1050 Table 'currency_country_rounding' already exists
Please try to fix this error and restart the update.
Response
{"valid":false,"errorMsg":"An exception occurred while executing '\nCREATE TABLE `currency_country_rounding` (\n `id` binary(16) NOT NULL,\n `currency_id` binary(16) NOT NULL,\n `country_id` binary(16) NOT NULL,\n `item_rounding` json NOT NULL,\n `total_rounding` json NOT NULL,\n `created_at` datetime(3) NOT NULL,\n `updated_at` datetime(3) NULL,\n PRIMARY KEY (`id`),\n KEY `currency_id` (`currency_id`),\n KEY `country_id` (`country_id`),\n CONSTRAINT `currency_country_rounding_ibfk_2` FOREIGN KEY (`currency_id`) REFERENCES `currency` (`id`) ON DELETE CASCADE ON UPDATE CASCADE,\n CONSTRAINT `currency_country_rounding_ibfk_3` FOREIGN KEY (`country_id`) REFERENCES `country` (`id`) ON DELETE CASCADE ON UPDATE CASCADE\n) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci\n ':\n\nSQLSTATE[42S01]: Base table or view already exists: 1050 Table 'currency_country_rounding' already exists"}
Nachdem ich ein Backup der Datenbank eingespielt habe und die currency_country_rounding Tabelle einfach gelöscht habe, geht es weiter. Nun mit folgendem Fehler:
(Ausgeblendet, weil wohl nur aufgetaucht wegen vorherigem Update-Versuchen und nicht wichtig für eigentliches Thema des Beitrages)
Der vorige Fehler den ich beim Update auf 6.4.0.0 hatte erscheint beim Update auf 6.4.1.0 noch immer:
Error
Received the following error message:
An exception occurred while executing 'ALTER TABLE `cms_page_translation` ADD CONSTRAINT `fk.cms_page_translation.cms_page_id` FOREIGN KEY (`cms_page_id`, `cms_page_version_id`) REFERENCES `cms_page` (`id`, `version_id`) ON DELETE CASCADE ON UPDATE CASCADE': SQLSTATE[23000]: Integrity constraint violation: 1452 Cannot add or update a child row: a foreign key constraint fails (`web25_foobar`.`#sql-3c5_d4eabc`, CONSTRAINT `fk.cms_page_translation.cms_page_id` FOREIGN KEY (`cms_page_id`, `cms_page_version_id`) REFERENCES `cms_page` (`id`, `version_id`) ON DE)
Please try to fix this error and restart the update.
Response
{"valid":false,"errorMsg":"An exception occurred while executing 'ALTER TABLE `cms_page_translation` ADD CONSTRAINT `fk.cms_page_translation.cms_page_id` FOREIGN KEY (`cms_page_id`, `cms_page_version_id`) REFERENCES `cms_page` (`id`, `version_id`) ON DELETE CASCADE ON UPDATE CASCADE':\n\nSQLSTATE[23000]: Integrity constraint violation: 1452 Cannot add or update a child row: a foreign key constraint fails (`web25_foobar`.`#sql-3c5_d4eabc`, CONSTRAINT `fk.cms_page_translation.cms_page_id` FOREIGN KEY (`cms_page_id`, `cms_page_version_id`) REFERENCES `cms_page` (`id`, `version_id`) ON DE)"}
Ich habe auch einen Fehler von 6.3.5.1 auf 6.4.1.0, ist doch fast der gleiche Fehelr wie auf 6.4.0.0?:
Error
Received the following error message:
An exception occurred while executing 'ALTER TABLE `cms_page_translation` ADD CONSTRAINT `fk.cms_page_translation.cms_page_id` FOREIGN KEY (`cms_page_id`, `cms_page_version_id`) REFERENCES `cms_page` (`id`, `version_id`) ON DELETE CASCADE ON UPDATE CASCADE': SQLSTATE[23000]: Integrity constraint violation: 1452 Cannot add or update a child row: a foreign key constraint fails (`c1w17db1`.`#sql-3d6_654287`, CONSTRAINT `fk.cms_page_translation.cms_page_id` FOREIGN KEY (`cms_page_id`, `cms_page_version_id`) REFERENCES `cms_page` (`id`, `version_id`) ON DELETE CASCADE O)
Please try to fix this error and restart the update.
Response
{"valid":false,"errorMsg":"An exception occurred while executing 'ALTER TABLE `cms_page_translation` ADD CONSTRAINT `fk.cms_page_translation.cms_page_id` FOREIGN KEY (`cms_page_id`, `cms_page_version_id`) REFERENCES `cms_page` (`id`, `version_id`) ON DELETE CASCADE ON UPDATE CASCADE':\n\nSQLSTATE[23000]: Integrity constraint violation: 1452 Cannot add or update a child row: a foreign key constraint fails (`c1w17db1`.`#sql-3d6_654287`, CONSTRAINT `fk.cms_page_translation.cms_page_id` FOREIGN KEY (`cms_page_id`, `cms_page_version_id`) REFERENCES `cms_page` (`id`, `version_id`) ON DELETE CASCADE O)"}
Das Problem scheint auch in der 6.4.1.0 noch zu bestehen. Beim Versuch, von 6.3.5.4 auf 6.4.1.0 upzugraden kommt:
`fk.cms_page_translation.cms_page_id` FOREIGN KEY (`cms_page_id`, `cms_page_version_id`) REFERENCES `cms_page` (`id`, `version_id`) ON DELETE CASCADE ON UPDATE CASCADE':
SQLSTATE[23000]: Integrity constraint violation: 1452 Cannot add or update a child row: a foreign key constraint fails
(`shop`.`#sql-101ae_169`, CONSTRAINT `fk.cms_page_translation.cms_page_id` FOREIGN KEY (`cms_page_id`, `cms_page_version_id`) REFERENCES `cms_page` (`id`, `version_id`) ON DELETE CASCADE ON UPD)
Der Versuch einer Korrektur mit
select * from cms_page_translation where cms_page_id not in (select id from cms_page);
delete from cms_page_translation where cms_page_id not in (select id from cms_page);
führt zwar dazu, dass das Update einen Schritt weiter läuft, aber dann kommt die Fehlermeldung
{"valid":false,"errorMsg":"Tables with multi column primary keys not supported"}
verwendete Versionen:
PHP: 7.4.20 MariaDB: 10.4.18
Hey @archery-analytics ,
Könntest du einen DB Backup wiederherstellen die Query ausführen mit dem delete in cms_page_translation und erneut aktualisieren?
Der Tables fehler kommt wenn die Migration zwei mal läuft
1 „Gefällt mir“
Hallo zusammen,
@Moritz_Naczenski
@Philipp-Schuch
die Aktualisierung von der Version 6.3.5.4 auf die Version 6.4.1 schlägt weiterhin fehl. Folgende Fehlermeldung bekomme ich:
Error
Received the following error message:
An exception occurred while executing ‚ALTER TABLE cms_page_translation ADD CONSTRAINT fk.cms_page_translation.cms_page_id FOREIGN KEY (cms_page_id, cms_page_version_id) REFERENCES cms_page (id, version_id) ON DELETE CASCADE ON UPDATE CASCADE‘: SQLSTATE[23000]: Integrity constraint violation: 1452 Cannot add or update a child row: a foreign key constraint fails (c1w3db2.#sql-4c91_6c7f5, CONSTRAINT fk.cms_page_translation.cms_page_id FOREIGN KEY (cms_page_id, cms_page_version_id) REFERENCES cms_page (id, version_id) ON DELETE CASCADE ON)
Please try to fix this error and restart the update.
Response
{„valid“:false,„errorMsg“:„An exception occurred while executing ‚ALTER TABLE cms_page_translation ADD CONSTRAINT fk.cms_page_translation.cms_page_id FOREIGN KEY (cms_page_id, cms_page_version_id) REFERENCES cms_page (id, version_id) ON DELETE CASCADE ON UPDATE CASCADE‘:\n\nSQLSTATE[23000]: Integrity constraint violation: 1452 Cannot add or update a child row: a foreign key constraint fails (c1w3db2.#sql-4c91_6c7f5, CONSTRAINT fk.cms_page_translation.cms_page_id FOREIGN KEY (cms_page_id, cms_page_version_id) REFERENCES cms_page (id, version_id) ON DELETE CASCADE ON)“}
Danke unf Gruß,
Die Kollegen schauen sich das gerade nochmal an.
Kann uns jemand bei dem das Update wegen der cms_page_translation nochmal fehlgeschlagen ist, nochmal einen db-dump von direkt vor dem update zukommen lassen?
Danke für den Tipp. Habe nochmals von vorne aufgesetzt, dann lief es durch. Habe also jetzt die 6.4.1.0 mit Ubuntu 18.04 am Laufen. Vielleicht von allgemeinem Interesse:
Hat man ein Ubuntu 18.04 mit allen Paketen auf dem aktuellen Stand, so ist die PHP Version die falsche (7.2) und die MariaDB Version ist falsch (10.4.19). Folgende Schritte habe ich für das Upgrade durchgeführt:
- Komplettes Backup der Maschine (Image/Snapshot)
- PHP 7.4 installiert + alle erforderlichen Extensions für diese Version (auch
curldie in der offiziellen Liste von Shopware fehlt https://docs.shopware.com/de/shopware-6-de/erste-schritte/systemvoraussetzungen) - PHP 7.4 im Apache enabled, 7.2 disabled
- MariaDB 10.4.19 komplett deinstalliert (außer natürlich den Daten), dann 10.4.18 mit
dpkginstalliert (siehe auch diesen Post dazu: Installation von mariadb ubuntu server 20.04 ) - Nochmals die Extension
ext-mysqlin der PHP Version 7.4 installiert. (Diese geht bei der Deinstallation von MariaDB 10.4.19 verloren und ohne diese zeigt der Shop nur eine weiße Seite) - Dafür gesorgt dass keine problematischen Datensätze in der Tabelle
cms_page_translationsind (s.o.) - Alle Plugins deaktiviert
- Upgrade 6.3.5.4 → 6.4.1.0 durchgeführt
- An die Version 6.4.1.0 angepasste Plugins installiert und aktiviert, cache gelöscht
War doch ein langer Weg bis endlich alles lief …
@archery-analytics schön das es geklappt hat. Um sicherzustellen das wir das Problem nicht weiterhin haben: Kannst Du mir sagen wie die problematischen Datensätze in der translation tabelle vorher aussahen?
Hast Du vllt noch den Dump der cms_page_* Tabellen von vor dem Update?