Aktuell beschäftigt mich ein mysteriöses Verhalten was ich mir überhaupt nicht erklären kann. Ok, der Shop ist eine Test-Umgebung mit 6.4.10 als Version und relativ jungfräulich.
Als Test-Artikel wurde mit Absicht ein Artikel mit langer Bestellnummer angelegt. Der besagte Artikel wird ganz normal im Frontend angezeigt. In einem eigenen Plugin versuche ich nun die ProduktId des Artikels zu ermitteln.
$productNumber = 'c05cdd01fa9f48869c82c45d64e54499';
$criteria = new Criteria();
$criteria->setLimit(1);
$criteria->addFilter( new EqualsFilter('productNumber', $productNumber) );
$productId = $this->ProductRepository->searchIds($criteria, $SalesChannelContext)->getIds();
print_r( $productId );
Und jetzt kommt der sonderbare Fall, denn die Funktion gibt keine ProduktId aus! Wenn ich aber eine andere Bestellnummer nehme, wie z.B.
$productNumber = 'SW10001';
wird mir eine ProduktId ausgegeben. Und es wird noch seltsamer, denn wenn ich ein Leerzeichen vor die lange Bestellnummer setze, also so:
Ein Schuss ins Blaue: Das Tabellenfeld für productNumber ist kürzer als deine lange Nummer. MySQL schneidet beim Einfügen leise etwas vom String ab. Das Query danach kann mit der vollen Nummer nichts mehr finden.
P.S. Versuche die Produkt-ID (also nicht productNumber, sondern der Primary Key) selbst zu erzeugen. Dann kannst du alle benötigten Daten an Sync-Endpoint senden und brauchst keine weitere REST-Kommunikation. Shopware hat mit der Wahl des PK-Datentyps etwas Gutes getan. Es sind einfach 16 byte, die du nach Belieben befüllen kannst.
Erst einmal vielen Dank für dein Feedback. Also wenn ich in die DB schaue, sieht alles korrekt aus. Die lange Nummer steht sauber in product_number drin. Irgendwie stehe ich da auf dem Schlauch.
Es riecht einfach nach MySQL. Unter dieser Prämisse fördert eine Suche eine Handbuchseite) zu Tage:
The following rules describe how conversion occurs for comparison operations:
Hexadecimal values are treated as binary strings if not compared to a number.
Ein expliziter Cast könnte vielleicht helfen, ist mit Symfony aber vermutlich ein PITA. Vermeide am besten hexadezimale Strings für Felder, die nicht Binary sind.
Bin in der Zwischenzeit auf die Ursache gestoßen. Da war wohl ein Steuerzeichen oder gar Leerzeichen drin. Keine Ahnung wie das in die DB gekommen ist, vermutlich irgendwo „schlamperhaft“ kopiert Thema damit erledigt.
Hm, der Witz ist, das Shopware selber im Zusammenhang mit Plugin-Tests (für den Shopware Store) solche Bestellnummern benutzt. Ich wäre darauf nicht gekommen.
Thema damit erledigt.