wir haben hier eine Datenbank die ursprünglich über die Oxid EE lief, wegen der Mandantenfähigkeit, jetzt aber als PE betrieben wird. Jetzt befinden sich doppelte Einträge in der Datenbank:
z.B. der selbe User mit der oxshopid oxbaseshop und 9.
Die Migrationsdatei setzt pauschal beide Shop-IDs auf 1 - was grundsätzlich (im Normalfall) auch okay wäre, jedoch wäre es sicher besser die Queries mit einem WHERE zu erweitern, oder nicht?
wenn ich das richtig verstehe, wollt Ihr mit einem Versionsupgrade von EE 5 auf 6 gleichzeitig von einer Edition EE auf PE wechseln. Ich fürchte, dieser Business-Case wurde einfach mal nicht bedacht, weil er - aus OXID-Sicht - natürlich völlig absurd erscheinen muss.
Könnt Ihr das nicht in zwei verschiedene Arbeitsschritte aufdröseln?
nicht ganz, der Shop hat einfach noch Bestanddaten in der Datenbank aus der EE-Zeit (schon länger her). Ich hab einfach in der Datei hinter alle Updates ein WHERE OXSHOPID = ‘oxbaseshop’; angehängt.
Mir geht’s auch nicht darum, dass ich ein Problem damit hätte, nur evt. kann es ja sein dass jemand beliebiges die entsprechenden Tabellen zweckentfremdet für z.B. CMS Anbindung nutzt. Vermutlich kommt dieser Fehler auch nur wirklich sehr selten vor ;D allerdings denke ich dass die Datei erheblich Schaden anrichten kann, wenn IDs auf 1 gesetzt werden, die das gar nicht 1 sein sollten.
Es ist natürlich nicht die Schuld von Oxid, wenn Benutzer komische Sachen machen Der Thread ist eigentlich mehr ein Hinweis. Ein Laie könnte Schwierigkeiten haben, zu erkennen dass z.B. in oxuser die Spalten OXSHOPID & OXUSERNAME einen uniquen Index bilden müssen, obwohl beides alleinstehen korrekter Weise nicht unique markiert ist.
In unserem Fall hatte sich ein Benutzer einfach zwei Mal angemeldet, für den alten Shop mit der alten Shop-ID und im neuen Shop mit der ID oxbaseshop. Die SQL-Datei setzt in beiden Fällen die Shop-ID auf 1, gibt halt Zoff in der Datenbank. Genauso, würden auch alle alten Bestände, Bestellungen, “Dinge” aus dem alten Shop in den neuen Shop “gemerged”.
Hallo Sioweb,
in eurem speziellen Fall wäre es vielleicht besser vor der Migration auf die 6er Version die Datenbank von den alten Dingen zu befreien. Also alle User, die nicht bei oxshopid = ‘oxbaseshop’ haben zu löschen. Ebenfalls die Bestellungen, etc…
Damit man nicht alle Tabellen manuell anfassen muss, könnte man ein Skript schreiben, dass zum Beispiel alle Benutzer, die nicht oxbaseshop als oxshopid haben als oxuser Objekt laden und dann mit $oUser->delete() das Objekt löschen. Dann werden auch die weiteren Daten des Objektes in der Datenbank gelöscht und man hat wieder einen sauberen Datenbankstand.
Nichtsdestotrotz wäre eine Eingrenzung in den Migrations-SQL-Statements mit "WHERE OXSHOPID = ‘oxbaseshop’ " wie du beschreiben hast angebracht.
Der Thread ist eigentlich mehr ein Hinweis. Ein Laie könnte Schwierigkeiten haben, zu erkennen dass z.B. in