Warum wurde eigentlich bei Shopware 6 nun der Datentyp BINARY eingeführt? Wie soll denn da die zukünftige Fehlersuche aussehen?
3 „Gefällt mir“
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.
3 „Gefällt mir“
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?
1 „Gefällt mir“
Ok, dann sollte Shopware wirklich nochmal überlegen auf Integer zurückzugehen, damit du die Ids am Telefon kommunizieren kannst.
1 „Gefällt mir“
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 ?
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 ;-))
Nicht nur die ID speichert die gesamten Daten im Binärformat. Wer auch immer auf diese Idee gekommen ist, hat wahrscheinlich noch nie versucht, Fehler zu beheben. wie ich bei Bedarf direkt auf Datenbankebene etwas finden und reparieren soll?!
Vor 4 Jahren hatte ich diesen Beitrag geschrieben. Auch wenn ich mich daran gewöhnen musste, ist es jedoch heute so, dass eine schnelle DB-Analsye (wie in SW5) nicht mehr bzw. nur noch erschwert möglich ist. Wenn Kunden anrufen, konnte ich früher bei bestimmten Problemen relativ zeitnah (mit Blick in die DB) eine Aussage treffen. Heute geht das am Telefon nicht mehr. Es bedarf mehr Zeit und somit auch höhere Kosten bei Fehlersuche, Analysen, Support etc… gegenüber dem Kunden. Besonders bei Analysen, in denen mehrere Tabellen involviert sind. Hat alles Vor- und Nachteile.
Die eigentliche Frage ist doch warum niemand „0xB7D2554B0CE847CD82F3AC9BD1C0DFCA 199,99“ schreibt wo man doch viel einfacher EUR 199,99 schreiben kann ?
Dem aufmerksame Shopware Debugger ist sicher auf gefallen, dass „0xB7D2554B0CE847CD82F3AC9BD1C0DFCA“ einfach nur EUR bedeutet.
Da frage ich mich doch warum so etwas machen muss ? Da hat einfach ein Informatiker nur ein theoretisches Modell gebaut, ohne das jemals in der Praxis zu überprüfen ?
Hm, ist ja nicht so, das SW5 ohne UUID nicht gelaufen ist. Ganz im Gegenteil es hatte programmiertechnische Vorzüge.