Ich habe eine grundsätzliche Frage zur Nutzung/Deklaration von Primary und Foreign Keys:
kann es sein, dass diese zwingend UUID-Felder sein müssen?
Ich laufe bei der Migration eines bestehendes Projektes, das eigene Tabellen nutzt (und zwar reichlich und intensiv), immer wieder in Exceptions, die darauf schließen lassen.
Beispiel:
Bei einem ->search mit einem EqualsFilter auf einem Integer-Feld, das in der Definition als FKField angelegt ist, lande ich bei einem
Argument 1 passed to Shopware\Core\Framework\Uuid\Uuid::fromHexToBytes() must be of the type string, int given,
und zwar in vendor/shopware/core/Framework/DataAbstractionLayer/Search/Parser/SqlQueryParser.php on line 230
$value = $query->getValue();
if ($field instanceof IdField || $field instanceof FkField) {
$value = Uuid::fromHexToBytes($value);
}
Ich habe in der Doku nichts dazu finden können bis dato, bräuchte dazu aber tatsächlich eine belastbare Aussage, weil davon tatsächlich das Migrations-Vorhaben abhängig ist.
Ganz lieben Dank 
UUID ist kein Feldtyp, sonder eine Helper-Klasse, da in Shopware 6 Ids vom Typ Binary sind. Die Klasse hilft dir dabei eine Unique-Id zu erstellen und in beide Richtungen zu konvertieren. Die Funktion erwartet hier einen String und kein Integer.
Beim Rest kann ich dir nicht helfen, da ich nicht weiß, wie dein Zeug angelegt ist.
Vielen Dank für die Antwort
Mir ist bewusst, was eine UUID ist. Und wie „mein Zeug angelegt“ ist: ich versuche ein Integer-Feld als FK-Feld anzulegen (new FKField() … aber eben auf einem Integer und nicht auf einem Binary).
Und meine Frage ist dazu ganz simpel:
Muss ein FKField bzw. auch ein IdField zwingend ein UUID („taugliches“) Feld sein?
Es wird nämlich grundsätzlich versucht, aus dem momentanen Wert des Feldes (in meinem Fall eben ein Integer und kein String!) eine UUID zu generieren.
Wenn es so sein sollte, dass sowohl ID- als auch FKFields nur vom Typ Binary sein dürfen, weil diese vom DAL zwingend als UUID behandelt werden, dann sollte das
a) deutlich in der Doku vermerkt sein oder
b) geändert werden
Shopware verfolgt das Prinzip in der gesamten Datenbank-Architektur. Von daher kansnt du schon davon ausgehen, dass zumindest der DAL auch zwingend eine UUID erwartet. Mit einer Änderung solltest du nicht rechnen.
Viele Grüße
Danke Eike
Ist das jetzt eine “offizielle” Aussage seitens Shopware?
Nicht falsch verstehen, bitte. Wenn du meine neuerliche Frage mit “Ja” beantwortest, bedeutet das für mich/uns, dass wir die bestehende Tabellestruktur redesignen müssen, bevor wir zu Shopware 6 migrieren können. Und der zeitliche Aufwand wäre nicht unerheblich … mein threatstartendes Anliegen ist also wirklich sehr ernst gemeint von mir.
Danke dir
im Prinzip brauchst du ja nur eine zweite Spalte mit der selben Id, nur eben als Binary:
ALTER TABLE `table_test`
ADD COLUMN `id_binary` BINARY(16) NOT NULL AFTER `id`;
Dann nur noch updaten:
UPDATE table_test
SET id_binary = CAST(HEX(id) AS binary)
So brauchst du die Primärschlüssel nicht umwerfen, sondern kannst den Fremdschlüssel einfach auf die neue Spalte verweisen.
Naja, ja
So einfach ist das alles nicht. Wir bekommen die Daten von aussen und da besteht die gesamte Datenlogik eben auf “klassische Primary und Foreign Keys als Integer”.
Der Datenbank ist das selbstredend Schnurz … die beachtet das Datenmodell, wie es ist (und sich bewährt hat) … ich kann dieses Modell nur ganz offensichtlich nicht mit dem DAL abbilden.
Das ist grundsätzlich ja kein Beinbruch. Aber (und ja, das ist wirklich ein “Aber”) dann möchte ich doch bitte zumindest in der Developerdoku an entsprechender Stelle einen deutlichen Hinweis lesen können. Ich habe das gesamte letzte Wochenende damit zugebracht, in meinem Code die fehler zu finden, die immer wieder zur o.g. Exception geführt haben. dal:validate war dabei nämlich überhuapt keine Hilfe … für den Validator scheint ein FKField auf einem Int kein Problem zu sein.
Ich bekomme meine Artikeldaten auch alle von außen und bereite die so auf, dass ich alle Schlüssel als Binary anlege. Das funktioniert einwandfrei mit Shopware’s DAL und ist wirklich kein großer Aufwand.
Die Dokumentation ist leider ein Thema, über das wir lieber den Mantel des Schweigens legen sollten.