wir haben bei SW s_articles_attributes Felder die wir für die weitere Verwendung später benötigen.
Nun ist uns aufgefallen, wenn ein Artikel neu angelegt wird, und auch die s_articles_attributes befüllt wird, dass jedoch die articleID nicht befüllt wird. Entsprechend kann man über die ID von s_articles keinen join zu den attributen machen.
Ist das bekannt ?
Oder gibts da einen Workaround zu ?
Vielleicht sollte ich noch erwähnen, dass der Artikel ja von Hause erst immer mit der ollen SW Artikelnummer angelegt wird beim ersten speichern. Wir ändern den logischerweise dann entsprechend wie wir das brauchen. Aber das ändert ja nix an der ID !
Um an die s_articles_attributes zu kommen müsste man ja sonst den umweg gehen, sich zu der article ID aus der article_details die detail-id zu holen und die dann auf die s_articles_attributes anwenden.
Ist zwar möglich, halte ich aber für etwas umständlich, wenn doch ein Feld für die articleID direkt in den attributen angelegt wird (Eigentlich)
Also, in neueren Shops gibt es in der Tabelle s_articles_attributes diese articleID gar nicht mehr, sondern nur noch articledetailsID. Macht auch mehr Sinn, wenn z.B. Varianten im Spiel sind. In diesem Falle ist es generell besser die articledetailsID abzufragen.
Grundsätzlich gebe ich Dir Recht, aber wir arbeiten mit Varianten und haben auch bei den Varianten in den attributen verschiedene Werte.
Übrigens haben wir 5.6.8 bei dem Projekt im Einsatz.
Ich habe aber auch sowieso festgestellt, dass die Doku von SW teilweise auch nicht korrekt / aktuell ist. Das ist aufgefallen, wenn man sich die s_user_addresses / s_user_default_billing (oder delivery) addresses ansieht.
Laut einem Teil der Doku sind die (default Tabellen) obsolete, seit einem Update, in einem anderen Teil der SW Doku wird die aber als noch relevant deklariert
Da gibt es eigentlich kein „jaein“. Eurer Shop wurde nur auf die Version geupdatet, da bleibt die articleID nur als tote Spalte im System - deswegen „null“. Aber in den aktuellen Version ist die articleID nicht mehr vorgesehen (die Spalte wird nicht mehr installiert). Braucht man auch nicht, da man über die articledetailsID (die wesentlich eindeutiger ist) auch an die articleID heran kommt.
Und besonders bei Varianten ist es wichtig auf die richtigen Artikel zu verlinken. Bei Varianten wäre so z.B. die articleID immer die selbe. Dann hättet ihr ein großes Problem, wenn die einzelnen Varianten unterschiedliche Angaben hätten. Ihr solltet also froh sein, dass man hier konsequent auf articledetailsID gegangen ist.
Und was Shopware und Dokus betrifft, ja da scheint man auf Kriegsfuß zu stehen. Leider werden die Dokus von Shopware nicht so mit Elan gepflegt, wie man für Shopware 6 Werbung macht oder Hersteller permanent mit Mails auf den Sack geht, damit sie ihre Plugins für SW6 zu recht machen. Dokus auf aktuellen Stand zu halten ist bei Shopware nicht gerade die Stärke. Am Ende sind es Forum-User die immer wieder darauf hinweisen müssen - mich eingeschlossen.
Ich habe mir das ganze Gebilde gerade nochmal genauer angesehen. Ich habe das Projekt von jemand übernommen, der ziemlich unsauber gearbeitet hat, und da waren solche Queries auch immer auf Basis von der ID. Und auch ohne weitere Fehlerbehandlung im Fehlerfall (das nur mal so am Rande)
Bei dem Projekt wovon ich gesprochen habe sind wohl noch von einem ex Programmierer Coreänderungen gemacht worden, die explizit noch auf die articleID Queries machen. Hatte aktuell ein Artikel geclont, und mich gewundert, warum der sich anders verhält als das original. Erst als ich die articleID in s_articles_attributes entsprechend gesetzt hab, hat sich auch der clone korrekt verhalten.
wenn ich mal Zeit und Lust finde, guck ich mir die Core Änderungen und die Queries mal genauer an und schau auch mal die auszulagern. Finde das echt eine unart in Core Dateien rumzupfuschen !