Hallo zusammen, wir haben den Eindruck dass das Migrationstool 5 auf 6 nicht sauber arbeitet.
Sollzustand:
Beim ersten Mirgrieren sollen alle Daten rübergezogen werden. (Migrationstool merkt sich, welche Daten bereits migriert wurden).
Bei allen weiteren Migrationsläufen sollen bereits migrierte Daten lediglich aktualisiert werden. Daten, die noch nicht migriert wurden sollen logischerweise angelegt werden.
Aber genau das tut das Tool nicht.
Wenn wir von SW5 auf SW6 einmal alles rüber migrieren, schaut das beim ersten Lauf auch gut aus. Sowie wir aber nochmal, und nochmal die Daten rüberziehen, haben wir teils doppelte Preise. (Nein, wir reseten nicht die Prüfsummen).
Wenn jetzt jemand kommt und sagt „ey, warum zieht ihr die Daten doppelt rüber?“ Ganz einfach: Weil sich Preise und Bestände ändern, Kunden hinzukommen, Passwörter geändert werden, am Live System gearbeitet wird und ein Live-System generell nie still steht. Deswegen ist es das normalste auf der Welt, die Daten im Laufe einer Umstellung mehrfach von LIVE in DEV rüberzuziehen, zu testen, weiterentwickeln usw.
Beispiel:
Produkt A kostet von 1 bis 10: 12,-€
Nach dem zweiten Lauf steht im Frontend (nochmal) von 1bis 10: 12,-€.
Wenn wir uns in der Datenbank die Tabelle price anschauen, haben wir hier doppelte Datensätze drin. Manche werden aktualisiert. Manche werden neu hinzugefügt. Da die Preise über die „product_id“ verbunden sind, werden manche auch doppelt im Frontend ausgegeben.
Wir haben das mit 6.4.20.2, 6.5.3.3, 6.5.4.0 und 6.5.4.1 getestet. Jedes Mal das gleiche Ergebnis.
Auch Dinge wie Cross-Selling werden neu geschrieben, d.h. wir haben am Artikel z.B. doppelt und dreifach stehen „Accessory Items“ und selbst Regeln werden immer und immer wieder neu angelegt. Das unschöne ist, dass man diese dann nicht einfach löschen kann, weil diese mit Bestellungen und anderen Punkten verknüpft sind.
Klar könnten wir das alles so laufen lassen und der Shop würde auch „irgendwie funktionieren“, aber es ist nicht Sinn der Sache in der Datenbank unnötiges Zeug zu haben.
Eine Lösung (zwar nicht an der Ursache, nur am Symptom) ist es, die entsprechenden Tabellen zu leeren oder sich an den Spalten „created_at“ und „updated_at“ zu orientieren, und hier die doppelten rauszuwerfen.
Was habt ihr für Erfahrungen mit dem Tool gemacht und wie geht ihr mit mehreren Migrationsläufen um?
VG