ich bekomme beim Update eine Fehlermeldung von Shopware 5.2 beta auf die 5.2 RC
Siehe Screenshot:
Error
Received the following error message:
Could not apply migration: SQLSTATE[42S21]: Column already exists: 1060 Duplicate column name 'title'
Please try to fix this error and restart the update.
Response
{"valid":false,"errorMsg":"Could not apply migration: SQLSTATE[42S21]: Column already exists: 1060 Duplicate column name 'title'"}
Weiß jemand, wie ich das Problem beheben kann oder wie ich rausfinde, wo genau die column title doppelt ist?
Vielen Dank
Hab ich schon als Ticket angelegt - würde auch gerne wissen, welche migrations-Datei ich löschen muss, um weiter zu kommen
Die Fehlermeldung schweigt sich da ja aus - und „Title“ gibt es ja nun mehrere in den Migrations-Scripts
Hab ich schon als Ticket angelegt - würde auch gerne wissen, welche migrations-Datei ich löschen muss, um weiter zu kommen
Die Fehlermeldung schweigt sich da ja aus - und „Title“ gibt es ja nun mehrere in den Migrations-Scripts
Und wie bekommt man nun die Beta wieder zum laufen?
Auf der SW Facebook Seite hat auch jemand geschrieben, das auch ein update von RC auf die Final nicht supportet wird, stimmt das?
Hallo,
das ein Update von RC auf Final nicht möglich sein wird, kann man sich aber auch schon denken, es steht ja nicht umsonst da, dass diese für Produktivsysteme nicht vorgesehen sind. Es steht aber auch in der Beschreibung vom RC selbst drin: " Achtung - Der Release Candidate dient ausschließlich zu Evaluierungszwecken und sollte nicht in Produktiv-Umgebungen eingespielt werden. Ein Updatepfad auf die finale Version wird nicht sichergestellt", siehe: http://community.shopware.com/Downloads\_cat\_448.html und „5.2.0 RC 1“.
Wahrscheinlich bleibt einen nichts anderes übrig, als entweder die Beta oder den RC (manuell) neu in der Testumgebung aufzuspielen.
Am besten per Console in das Shopware Installationsverzeichnis gehen dann das Updatescript per
php recovery/update/index.php
aufrufen.
Auch hier erscheint jetzt die SQL Fehlermeldung.
Jetzt per phpmyadmin die tabelle s_schema_version aufrufen und nach Name sortieren. Wenn man scrollt findet man auf der rechten Seite wo ansonsten immer eine NULL eingetragen ist dieses SQL Statement (Fehlermeldung). Jetzt überprüfen ob genau dieser Eintrag schon existiert (also ob die neu eingetragene Tabelle schon vorhanden ist), wenn ja, dann die alte Tabelle löschen und in der neuen, wo der Fehler steht bei dem Fehlereintrag den “Haken” setzen (error_msg) so das der Fehler dann gelöscht wird. Dann noch das gleiche Datum bei “complete_date” einfügen wie es auch in " start_date" steht.
Jetzt wieder per Console
php recovery/update/index.php
aufrufen.
Der Fehler erscheint wieder. Also wieder in die Datenbank und s_schema_version wieder öffnen und den beschriebenen Vorgang wiederholen.
Dieses müsst ihr je nach Konfiguration 5 - 10 x wiederholen, dann läuft zum schluss das Update durch und die Version 5.2.0 RC1 läuft sauber ohne Fehler
Wer als Early Adopter ab dem RC Arbeit reinsteckt, sollte nicht im Regen stehen gelassen werden. Wenn es tatsächlich ein echter RC ist, sollte sich ja nicht mehr viel ändern und dann sollte wenigstens ein Update auf die 5.2.1 möglich sein, wenn nach wie vor die 4.2 als Basis zum Update angegeben wird.
Ich hab kein Problem damit, wenn eine Beta oder RC nicht updatefähig ist, das würde den Updatecode auch nur unnötig aufblähen.
Womit ich aber ein Problem habe ist, wenn mir im Backend der Autoupdater ein Update von Beta auf RC anbietet, und das dann angestossene Update selber auch wieder keine Prüfung macht, und munter startet - und alles zerballert. Egal ob Testumgebung - auch da kann es „stören“ - ich gehe dann nach der Verfügbarkeitsmeldung im Backend sicherlich nicht auf die Suche bei Fratzenbuch, Zwitscher oder sonstwo um zu gucken, ob irgendwo versteckt eine abweichende Meldung ist.
Dann sollte in der Beta und in der RC der autoupdater deaktiviert oder nicht vorhanden sein
Das Update sollte schon prüfen, ob es „berechtigt“ ist
Und dann sollte man endlich mal überlegen, ob man die Migrations-Scripte einfach mal etwas „aussagefreudiger“ und „unkritischer“ macht.
Ich sag da nur: Update auf 5.1.5 bei All-Inkl. gehosteten und „mapping_id“
Wenn einfach nur ein ALTER TABLE eine neue Spalte einfügt oder einen INDEX setzen möchte, die/der bereits vorhanden ist, besteht eigentlich kein Grund für einen Abbruch - und wenn doch, wäre es nützlich, wenn das Script mal seinen eigenen Dateinamen preisgeben würde.
Am besten per Console in das Shopware Installationsverzeichnis gehen dann das Updatescript per
php recovery/update/index.php
aufrufen.
Auch hier erscheint jetzt die SQL Fehlermeldung.
Jetzt per phpmyadmin die tabelle s_schema_version aufrufen und nach Name sortieren. Wenn man scrollt findet man auf der rechten Seite wo ansonsten immer eine NULL eingetragen ist dieses SQL Statement (Fehlermeldung). Jetzt überprüfen ob genau dieser Eintrag schon existiert (also ob die neu eingetragene Tabelle schon vorhanden ist), wenn ja, dann die alte Tabelle löschen und in der neuen, wo der Fehler steht bei dem Fehlereintrag den „Haken“ setzen (error_msg) so das der Fehler dann gelöscht wird. Dann noch das gleiche Datum bei „complete_date“ einfügen wie es auch in " start_date" steht.
Jetzt wieder per Console
php recovery/update/index.php
aufrufen.
Der Fehler erscheint wieder. Also wieder in die Datenbank und s_schema_version wieder öffnen und den beschriebenen Vorgang wiederholen.
Dieses müsst ihr je nach Konfiguration 5 - 10 x wiederholen, dann läuft zum schluss das Update durch und die Version 5.2.0 RC1 läuft sauber ohne Fehler
Viel Spass
Danke für den Workaround, allerdings wirds beim Update von der RC auf die Stable wieder Probleme geben, deswegen habe ich meine RC Installation jetzt eingestampft.
Also wieder in die Datenbank und s_schema_version wieder öffnen und den beschriebenen Vorgang wiederholen.
Also wieder in die Datenbank und s_schema_version wieder öffnen und den beschriebenen Vorgang wiederholen.