Datenbank Migration 4.10 zu 6.2

Hallo zusammen,

ich möchte gerne die Datenbank von CE 4.10 Shop auf einen neuen 6.2 Shop migrieren. Dazu habe ich diese Anleitung gefunden, über die hier im Forum schon mehrfach geschrieben wurde.

Ich habe dazu die Datenbank vom 4.10 Shop exportiert (alle Module deaktiviert!) und im 6.2 Shop importiert. Dann habe ich die beiden mitgelieferten sql-Dateien und danach den Befehl vendor/bin/oe-eshop-db_migrate migrations:migrate ausgeführt. Als Ergebnis bekomme ich nach diesem Befehl

“No migrations to execute”

und wenn ich den Shop im aufrufe folgende Fehlermeldung:

Fatal error: Uncaught Symfony\Component\DependencyInjection\Exception\ServiceCircularReferenceException: Circular reference detected for service “Psr\Log\LoggerInterface”, path: “Psr\Log\LoggerInterface → Psr\Log\LoggerInterface”. in /home/shop_directory/vendor/symfony/dependency-injection/Container.php:297 Stack trace: #0 /home/shop_directory/source/overridablefunctions.php(209): Symfony\Component\DependencyInjection\Container->get(‘Psr\Log\LoggerI…’) #1 /home/shop_directory/vendor/oxid-esales/oxideshop-ce/source/Core/Registry.php(329): getLogger() #2 /home/shop_directory/vendor/oxid-esales/oxideshop-ce/source/Core/Module/ModuleChainsGenerator.php(420): OxidEsales\EshopCommunity\Core\Registry::getLogger() #3 /home/shop_directory/vendor/oxid-esales/oxideshop-ce/source/Core/Module/ModuleChainsGenerator.php(344): OxidEsales\EshopCommunity\Core\Module\ModuleChainsGenerator->onModuleExtensionCreationError(‘z_multifilter_o…’) #4 /home/shop_directory in /home/shop_directory/vendor/symfony/dependency-injection/Container.php on line 297

Den nachfolgenden Befehl vendor/bin/oe-eshop-db_views_generate kann ich wegen dieser Fehlermeldung schon nicht mehr ausführen.
Hat jemand eine Idee, was hier der Fehler ist?
Vielen Dank schon im Voraus.

Das ist ein Modul von mir, eine Version für 6.2 ist verfügbar. Generell kannst du bei einer Migration von 4.10 auf 6.x die Module nicht einfach mitnehmen, du musst erst die 6.x ohne Module installieren, neue Versionen der Module besorgen und diese neu installieren.

Kann nicht richtig sein, wenn du die DB von 4.10 mit den Skripts auf 6.0 Stand gebracht hast dann gibt es Migrations zur 6.2.

Genau das ist der Plan. Deshalb habe ich die Module im 4er Shop deaktiviert vor dem Export der DB und habe sie in einen frischen Shop importiert. Ich möchte nur die Benutzer/Bestell/Artikeldaten übernehmen, nicht die alten Module.

Hätte ich auch gesagt. Warum er nichts findet ist mir schleierhaft.

Wie bekomme ich denn die alten Module aus der Datenbank raus? Im Backend sind sie alle deaktiviert.

DELETE FROM oxconfig WHERE OXVARNAME LIKE ‘%module%’

Dann kann man noch oxtplblocks leeren. Die Module erst dann ins modules Verzeichnis der 6.x kopieren wenn man sie neu installiert.

Normal ist das so: die Migrations stehen im Filesystem in source/migration/data. In der DB gibt es die Tabelle oxmigrations_ce, da steht drin welche schon ausgeführt wurden, die die noch nicht in der Tabelle stehen werden ausgeführt.

Also ich habe beides nochmal gemacht vor dem Export der DB. Trotzdem kommt der gleiche Fehler wie oben beschrieben, auf dem er sich auf das Modul z_multifilter bezieht.
In der Tabelle oxconfig sind noch etliche Zeilen, wo in OXMODULE “module:z_multifilter” steht. Die habe ich jetzt auch nochmal rausgelöscht, aber ohne Erfolg.
Was kann ich noch tun?

wurden die Einträge in oxconfig ganz sicher gelöscht?
Ich habe schon ein Paar mal gesehen, dass eine Datenbank das Löschen von Daten nicht anhand des Primärschlüssels verweigert hatte.
Führe mal SELECT * FROM oxconfig WHERE OXVARNAME LIKE ‘%module%’ im PhpMyAdmin o.ä. aus, kommt da was raus?

Da kommt nichts.

wurde nach dem Löschen der Einträge auch tmp geleert?

Ahhhh, DAAAANKE!!! Ja, das zeigt zumindest schon mal wieder den Shop. Danke @vanilla_thunder .

Den Befehl vendor/bin/oe-eshop-db_migrate migrations:migrate kann ich allerdings immer noch nicht ausführen bzw. es kommt immer noch der Hinweis, dass es nichts zu migrieren gibt. Ist das problematisch? Im Order source/migration/data sind auch Dateien zu finden.

Ja das ist ein Problem. Was steht denn in der DB-Tabelle oxmigrations_ce?

Da bekomme ich folgende Daten zurück:
20170718124421
20171018144650
20180214152228
20180228160418
20180703135728
20180928072235

Die Frage ist wie kommen die Daten da rein, entweder hast du Migrations schon ausgeführt oder die Tabelle war von einem früheren Update-Versuch noch da. Im Update-Script migrate_ce_5_3_to_6_0.sql steht dieses drin:

INSERT IGNORE INTO `oxmigrations_ce` (`version`) VALUES
('20170718124421'), ('20171018144650');

Direkt nach dem Ausführen des Updatescripts sollten also nur zwei Werte drin stehen, und der Rest wird dann durch

vendor/bin/oe-eshop-db_migrate migrations:migrate

ausgeführt. Erst wenn das gleiche Kommando dann nochmal ausgeführt wird kommt:

“No migrations to execute”

Also ich habe jetzt mal alle Daten aus der oxmigrations_ce Tabelle gelöscht und den Befehl vendor/bin/oe-eshop-db_migrate migrations:migrate nochmal ausgeführt. Nun hat er die Scripte ausgeführt.
Ich hoffe, dass genügt dann für die Datenbank-Migration.

Die ersten zwei hat er dann quasi doppelt ausgeführt weil die sind in OXID 6.0 schon drin, aber ich denke nicht dass das schadet.

Super. Vielen Dank dir. :slight_smile:

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.