Debugging einer 5 auf 6 Migration unter SW 6.6

Shopware 6 (German) Programmierung
1

Der MigrationsAssistent unter 6.6. ist ja mittlerweile sehr reduziert bzgl. des Debuggings. Vorher gab es ja noch die Möglichkeit einzelne Step zu überspringen oder mit limit die Anzahl der Sätze zu begrenzen.
Mittlerweile gibt es nur noch dataSelection ! Da muss ich dann immer über 100000 Sätze drüber. Wer hat sich das bloss ausgedacht; oder gibt es hier eine „Magie“, die ich noch lernen muss ?

2

Ehrlich gesagt kenn ich so eine Methode nicht - oder mir nicht aufgefallen.

Man kann ja einzelne Prozesse (z.B. Migration nur von Produkten) starten. Die Migration läuft auch komplett im HIntergrund ab - das war nicht immer der Fall. Ich weiß jetzt noch nicht so richtig, wo das Problem besteht. Und wenn die Log-Datei scheiße groß wird, dann ist vielleicht noch „dev“ aktiv oder die SW5-Datenbank hat grobe Fehler. Aber das kann ich zur Stunde hier schlecht beurteilen.

3

Also wir haben da so in etwa das selbe Problem. SW5 → SW6 Migration. Soweit hat alles gepasst bis auf den Import der Kunden. Denn dort werden alle Bestellungen und PDF mit importiert. Bei 100000 Kunden sind das 450000 Bestellungen und dazu jeweils die PDF??

Die Migration läuft 2 Tage und dann sind nur 333 Bestellungen importiert. Im migrationlog in der DB sieht man das es mapping fehler sind( denke ich) also das die Zuordnungen nicht klappen. Hier sind 2 Fehler aus dem Log in der DB:

  • Fehlercode: SQLSTATE[23000]: Integrity constraint violation: 1452
  • Fehlermeldung: Cannot add or update a child row: a foreign key constraint fails

und

SQLSTATE[23000]: Integrity constraint violation: 1452 Cannot add or update a child row: a foreign key constraint fails (shopware.order_line_item, CONSTRAINT order_line_item_ibfk_1 FOREIGN KEY (product_id, product_version_id) REFERENCES product (id, version_id) ON DELETE SET NULL ON UPDATE CASCADE)

Kann da jemand helfen?

4

Das Basis Problem ist, dass die Migration komplett als Blackbox, abläuft. Und die einzelnen Schritte immer nach dem gleichen Muster ablaufen. sprich laden der Daten (fetch), dann schreiben (wobei hier dann auch das Mapping) stattfindet.

Mein aktuelle „best-practise“ sieht soaus:

  • auf jeden Fall bis zum finalen Setup lokal arbeiten. Also DBs (SW5 und SW6) lokal ziehen und auf einem performanten Rechner arbeiten.

  • zum testen habe ich die „großen“ Basis-Tabellen umbenannt s_user, s_artikel heißen dann s_user_raw und s_artikel_raw und darauf liegt dann jeweils immer ein view der das ganze auf 100-200 Sätze reduziert.

  • daneben habe ich mir Skripte gebaut, die das Mapping und die Ergebnis-Tabelle zurücksetzen können (sprich leeren). Darin ist dann auch die swag_migration_logging tabellen.

  • daneben kann ich die swag_migration_mappping mit einer CSV Datei befüllen. Praktisch wenn bestimmte Daten einfach nicht wollen.

  • wirklich alles dokumentieren und notieren. und vielleicht direkt in Skripte einbauen.