Warum wurde eigentlich bei Shopware 6 nun der Datentyp BINARY eingeführt? Wie soll denn da die zukünftige Fehlersuche aussehen?
3 Likes
Würde mich auch interesseieren welche Designentscheidung dem zugrunde lag. Performance, Security?
Siehe https://de.wikipedia.org/wiki/Universally_Unique_Identifier
und Shopware empfiehlt: https://www.adminer.org/de/
Viele Grüße
ja schon, aber warum BINARY? Ohne jetzt die MySQL Doku zu wälzen, vermute ich weils platzsparender als VARCHAR ist?
Egal welcher Hintergrund, es macht in Zukunft die Suche in der Datenbank bei Problemen nicht einfacher.
2 Likes
wieso das denn? Muss man halt immer die Id einmal c&p aber ansonsten sind uuids einfach praktischer
Wieso c&p? Wer will hier was kopieren und einfügen?
Manchmal ist es so, dass man bstimmten Datensätze in den Tabellen überprüfen muss. Viele Einträge sind hierbei über mehrere Tabellen verteilt. Mit den IDs wie in SW5 ist das relativ schnell gemacht wenn der Kunde eben am Telefon ist. Mit UUID ist das optisch wesentlich schwerer zu erkennen.
Eine ID z.B. 15 ist besser und schneller von Auge erfassbar als eine ID z.b. 271F02B95B7E457496CEE509CC781EA5 oder ist jemand anderer Meinung?
Ok, dann sollte Shopware wirklich nochmal überlegen auf Integer zurückzugehen, damit du die Ids am Telefon kommunizieren kannst.
1 Like
Der ein oder andere wird noch hierüber stolpern. Uns ist es vorerst egal, da wir unseren Kunden SW6 noch nicht anbieten wollen.
ja ich … ich stolpere schon seit stunden. Wie bekomme ich denn nun die Binary in eine UUID zurück ich muss Variannten optionen löschen und weiß gerade nicht wie ich jetzt die ID unter den Binarys finde? HAt da jemand einen Tipp ?
UUID zu BINARY in SQL:
X'UUID'
Danke Max, konnte mir nun bereits helfen in dem ich die tabelle product gezogen habe. Dort stehen zumindest die Produktnummern noch in klartext, und daneben die passende id in binary. Konnte es lösen. Aber gebe R4M zu 100% Recht. Überoptimieren zu kosten von usability.
bzw dachte ich konnte es lösen. Ich habe immernoch das Problem das sich die varianten wieder neu generieren (die falschen) außer bei einer Variante von 4 Varianten wo es falsch ist läuft es. Da habe ich scheinbar was richtig gemacht. Max weisst du das Vorgehen in der Datenbank um falsch angelegte Varianten optionen aus einem Varianten Artikel zu entfernen? @Max_Shop
EDIT: ich habe durch einen kleinen aber hilfreichen fehler immerhin nun die Idee wo die Daten in die Datenbank geschrieben werden
(XXXX.product_configurator_setting, CONSTRAINT fk.product_configurator_setting.property_group_option_id FOREIGN KEY (property_group_option_id) REFERENCES property_group_option (`i)
ich nehme an da muss ich ansetzen und die DAten rauslöschen? Nur welche genau? Muss ich die Produkt ID suchen und den zugewiesenen Option ID Wert ?
Erledigt. Variantenkonfiguration exportieren, und dann in der product_configurator_setting nach parent id und der varianten id suchen und aus der parent rauslöschen.
Danach auch aus der Tabelle Product_option die entsprechenden Varianten product_ids suchen und die group configurator id, die falsch ist rauslöschen, dann verschwinden die falschen varianten auch aus dem backend.
Hat bei mir geklappt, falls andere danach suchen. Helfe gern falls jemand fragen hat.
Es sind nicht nur die ID: die Datenbank ist auch konsequent normalisiert, erlaubt Versionen von Datensätzen, hat sehr viele Tabellen und oft auch JSON in Felder stehen.
Alles nicht geeignet, um selber mal schnell aus den Tabellen die Funktion zu entdecken.
Also frisch voran und die API genutzt, das Tool der Wahl ist Postman.
Die Responses der API sind umfangreich und erhellend!
… und die UUIDs sind immer als Strings angezeigt ;-))