Datenbank Update/Migration auf V6


#1

Hallo,

ich kämpfe zur Zeit mit dem Update von CE 4.10.6 auf 6.0.

Ich habe nun schon etliches gelesen und trotzdem im Endeffekt mindestens ein Verständnisproblem.

  1. Habe ich das Shopverzeichnis “SHOP” auf dem Server komplett in “SHOP60” kopiert.
  2. Habe ich die Datenbank gesichert.
  3. Habe ich im Verzeichnis “SHOP60” das Projekt “XX60” angelegt.
  4. Habe ich über den Serverpfad XXX/SHOP60/XX60/vendor/ einen neuen Shop und eine neue Datenbank angelegt.
  5. Nun müssten die Daten von der alten Datenbank (SHOP) in die neue (SHOP60) kopiert werden - und hier geht es los…

Ich könnte das Backup der Datenbank in eine neue einspielen und über phpmyadmin die Migrations-SQL einspielen. Dann habe ich die Daten immer noch nicht in der neuen Datenbank.

Wenn ich dann über das Terminal im Ordner “XXX/SHOP60/XX60/” das Migrationsscript “vendor/bin/oe-eshop-db_migrate migrations:migrate” laufen lasse (hier habe ich z.Zt. Fehlermeldungen), werden doch noch die Zugangsdaten der alten Datenbank benötigt???

Was habe ich hier übersehen, bzw. was übersetzt mir “G” nicht?

mfg

Gert


#2

Die migrierte DB ersetzt die DB die du beim Shop-Setup der V6 angelegt hast. Also du gehst in deine frisch angelegte Datenbank des neuen Shops, und löschst alle Tabellen und views. Dann spielst du das Backup der DB des 4.10er Shops ein, führst die beiden Updatescripte nacheinander aus, führst den migrations-command und den Update-Views-command aus.
https://docs.oxid-esales.com/developer/en/6.0/update/eshop_from_53_to_6/database.html


#3

Hier ist der Anfang der Anleitung:
https://docs.oxid-esales.com/developer/en/6.0/update/eshop_from_53_to_6/index.html

Im ersten Abschnitt “Files” gehts um die parallele Installation von V6 neben dem zu-aktualisierenden Shop.


#4

Hallo,

@leofonic Danke, das ist das, was mir gefehlt hat.

@vanilla_thunder Danke, das kannte ich natürlich, allerdings konnte ich mit meinem Laien-Englisch und “G” den Schritt nicht erkennen.

Dann werde ich das erst mal mal testen und schauen, was für einen Fehler das Script danach ausspuckt…

mfg

Gert


#5

Hallo,

wenn ich die 2 Migrationsscripte ausführe, erhalte ich:

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

Loading configuration from command option: /XXX/vendor/oxid-esales/oxideshop-facts/src/Config/…/…/…/…/…/source/migration/migrations.yml

                Oxid Migrations CE                    

No migrations to execute.

xxx/$ vendor/bin/oe-eshop-db_views_generate
Uncaught exception. See EXCEPTION_LOG.txt
There was an error while regenerating the views. Please look at EXCEPTION_LOG.txt for more details.

Wenn ich in die EXCEPTION.log schaue, steht da:

[23 Dec 16:44:25.607681 2017] [exception] [type OxidEsales\Eshop\Core\Exception\DatabaseErrorException] [code 1054] [file /XXX/vendor/oxid-esales/oxideshop-ce/source/Core/Database/Adapter/Doctrine/Database.php] [line 947] [message Unknown column ‘oxshops.oxtaxnumber’ in ‘field list’]
[23 Dec 16:44:25.607681 2017] [exception] [stacktrace] #0 /XXX/vendor/oxid-esales/oxideshop-ce/source/Core/Database/Adapter/Doctrine/Database.php(621): OxidEsales\EshopCommunity\Core\Database\Adapter\Doctrine\Database->convertException(Object(Doctrine\DBAL\Exception\InvalidFieldNameException))
[23 Dec 16:44:25.607681 2017] [exception] [stacktrace] #1 /XXX/vendor/oxid-esales/oxideshop-ce/source/Core/Model/BaseModel.php(732): OxidEsales\EshopCommunity\Core\Database\Adapter\Doctrine\Database->select(‘select oxshops...') [23 Dec 16:44:25.607681 2017] [exception] [stacktrace] #2 /XXX/vendor/oxid-esales/oxideshop-ce/source/Core/Model/BaseModel.php(713): OxidEsales\EshopCommunity\Core\Model\BaseModel->getRecordByQuery('selectoxshops…’)
[23 Dec 16:44:25.607681 2017] [exception] [stacktrace] #3 /XXX/vendor/oxid-esales/oxideshop-ce/source/Core/Model/BaseModel.php(665): OxidEsales\EshopCommunity\Core\Model\BaseModel->assignRecord(‘select `oxshops…’)
[23 Dec 16:44:25.607681 2017] [exception] [stacktrace] #4 /XXX/vendor/oxid-esales/oxideshop-ce/source/Core/DbMetaDataHandler.php(562): OxidEsales\EshopCommunity\Core\Model\BaseModel->load(‘1’)
[23 Dec 16:44:25.607681 2017] [exception] [stacktrace] #5 /XXX/vendor/oxid-esales/oxideshop-db-views-generator/src/ViewsGenerator.php(39): OxidEsales\EshopCommunity\Core\DbMetaDataHandler->updateViews()
[23 Dec 16:44:25.607681 2017] [exception] [stacktrace] #6 /XXX/vendor/oxid-esales/oxideshop-db-views-generator/generate_views.php(80): OxidEsales\DatabaseViewsGenerator\ViewsGenerator->generate()
[23 Dec 16:44:25.607681 2017] [exception] [stacktrace] #7 /XXX/vendor/oxid-esales/oxideshop-db-views-generator/oe-eshop-db_views_generate(4): require_once(’/is/htdocs/wp12…’)
[23 Dec 16:44:25.607681 2017] [exception] [stacktrace] #8 {main}
Ich habe mir einen Dump der neuen DB gezogen. Ich kann dort kein Felt “oxtaxnumber” finden. Wenn ich das richtig übersetze, dürfte das die Steuernummer in der Tabelle “oxshops” sein???

Wo kann ich noch suchen, bzw. was kann ich hier machen?

mfg

Gert


#6

Die 2 update-Scripte hast du ausgeführt? migrate_ce_5_3_to_6_0.sql und migrate_ce_5_3_to_6_0_cleanup.sql aus dem Link? Falls nicht musst du das noch machen.

Die Fehlermeldung liegt evtl. an Daten im /tmp-Verzeichnis, leere dieses mal vor dem Ausführen der commands.


#7

Hallo leofonic,

die Update-Scripte wurden ohne Fehlermeldung ausgeführt. Ich habe das noch einmal an einer 2. Installation getestet - das gleiche Verhalten.

Das vendor/tmp-Verzeichnis habe ich gelöscht.

Das Migrationsscript bringt mir wieder “No migrations to execute.”

???

mfg

Gert


#8

source/tmp meinst du? Nicht löschen, nur leeren :wink:

Das ist OK so, ist kein Fehler. Ich meinte den Fehler beim Generieren der Views, da könnte /tmp leeren evtl. helfen.


#9

Wo ist denn vendor/bin/oe-eshop-db_migrate migrations:migrate auf dem Server abgelegt? Bei mir kommt immer no such file or directory.


#10

Na genau in diesem Verzeichnis.


#11

Hallo,

nun habe ich wieder etwas Zeit, mich um die Installation zu kümmert…

@leofonic
source/tmp meinst du? Nicht löschen, nur leeren

klar, hatte ich auch so gemacht.

Nun habe ich einige Installationsversuche durchgeführt und damit auch eine gewisse Routine. Zur Zt. hänge ich allerdings am “Maintenance mode” und das ziemlich hartnäckig.

Ich versuche mal die Schritte zu Beschreiben, die ich bisher erfolgreich durchgeführt habe:

  1. Projekt erstellen
  2. Installation durchführen - das Backend und der Shop funktionieren
  3. Über mysqldumper den alten Dump der CE4.10.6 - ohne oxconfig importiert
  4. In PHPMyAdmin die “migrate_ce_5_3_to_6_0.sql” und die “migrate_ce_5_3_to_6_0_cleanup.sql” "importiert.
  5. In Putty “vendor/bin/oe-eshop-db_migrate migrations:migrate” - (No migrations to execute.) und
  6. vendor/bin/oe-eshop-db_views_generate mit Fehlermeldung ausgeführt.
  7. Im Backend eingeloggt und dort die Views angelegt.

Damit funktioniert das Backend - es werden alle Produkte usw. angezeigt und ich kann bearbeiten.

Was nicht funktioniert ist der Shop und die Artikelvorschau, die mir bei allen 4 weiteren Test-Installationen einen “Maintenance mode” bringen.

In meiner “EXCEPTION_LOG.txt” steht nix drin und das PHP5.6-Log von HE sagt mir von diesem Pfad nix.

Wo kann ich noch suchen? Hat jemand eine Idee?

mfg

Gert


#12

Ist den im Backup unter Grundeinstellungen->Stamm bei Aktiv der Hacken gesetzt!?
Der Maintenance mode ist ja nichts anderes als die alte Offline Seite.

Steffen Winde


#13

Hallo Steffen,

kann ich z.Zt. leider nicht beantworten. Ich bilde mir aber ein, dass bei den frisch installieren CE60 dort kein Haken gesetzt war und das Frontend trotzdem funktionierte…

Zur Zeit kann ich mit keiner Testinstallation arbeiten, weil die Projekterstellung wegen Speichermangel nicht funktioniert und bei ich allen Testinstallationen eine weiße Seite, oder den Wartungsmodus erhalte, warum auch immer…

PS. Ich werde weiter testen…

mfg

Gert


#14

Achtung, es gibt da zwei Checkboxen: “aktiv” und “live Modus”.
wenn “aktiv” aus ist, gibts kein Frontend.
wenn “live Modus” aus ist, wird nur kein Cache beachtet und jedes mal aufs neue generiert.

kann man auch im Demoshop sehen


#15

Hallo vanilla_thunder,

wie schon oben geschrieben, ärgert mich z.Zt. mein Server??? etwas. Ich komme gar nicht in die versch. (Test-) Admin-Bereiche…

Ich habe aber mal in die DB geschaut, zu mindestens bei dieser einen sind “OXACTIVE” und “OXPRODUCTIVE” auf “1”…

PS: Da ich ja die “alten” Dumps importiert habe, habe ich die Tabelle “oxshops” auch importiert. Und das sind Dumps von Live-Systemen…

mfg

Gert


#16

Hallo,

gestern lies mich der Server/composer wieder arbeiten. Ich habe 3 Projekte angelegt und installiert und es funktioniert alles, wie es eigentlich sollte.
Was es gewesen ist - also ich vermute eine Mischung aus (Eigen-) Fehler und Caching-Problemen/Einstellungen (beim Server, denn ich verwende ja auch immer versch. Browser, die auch beim Schließen alles löschen).

Also, wenn ich die 3 Projekte testweise und erfolgreich auf die CE6.0 migriert habe, werde ich mich mal an ein ToDo machen. Das finde ich dann auch wieder…

mfg

Gert


#17

Hallo Gert,
hast du eine ToDo gemacht, wäre sehr hilfreich.
lg helmut


#18

Hallo,

mfg

Gert


#19

Danke für den Link.

Ich habe den aktuellen Shop 6.0.2 installiert und möchte nun die Datenbank von meinem
alten Shop 4.10.1 (1,6GB!) migrieren.
Der Data Import funktioniert noch ohne Fehler.

migrate_ce_5_3_to_6_0.sql -> Hier habe ich schon die erste Fehlermeldungen
19:15:23 UPDATE oxshops SET OXVERSION = ‘6.0.0’ Error Code: 1146. Table ‘oxold.oxshops’ doesn’t exist 0.000 sec


#20

Hallo Helmut,

ich bin nun hierbei kein “Fachmann”…

Ich sehe hier, wenn Du von der CE 4.10.1 migrierst, könnte die SQL die falsche sein???

Table ‘oxold.oxshops’ doesn’t exist

Also wenn Du in der DB der CE 4.10.1 oxshops die Spalte “oxold” findest, würde ich diese (nach einem Backup) testweise löschen.

Wenn nicht, würde ich versuchen, diese in der DB der CE 6.0 zu erstellen - allerdings habe ich in meiner DB (CE 6.02) Tabelle “oxhops” keine Spalte “oxold”…

Wenn das nicht hilft, habe ich dann das Migrationscript portionsweise in phpmyadmin ausgeführt und das ausgelassen, was nicht funktioniert. Meistens waren das keine “wichtigen” Sachen und wenn der Shop funktioniert…

1,6GB - hier würde ich versuchen zu minimieren. Statistik löschen???

mfg

Gert