Unnötiges JOIN in Funktion getAttributesCount()

[noRiddle]

In der product-Klasse wird in der Query in der Methode getAttributesCount() ein JOIN auf die Tabelle products_options gemacht. Mir erschließt sich der Grund dafür nicht und ich bin der Ansicht, daß man das JOIN entfernen kann und somit, insbesondere bei vielen Attributen, einen Prerformance-Gewinn ereicht.
Eine Abhängigkeit von aktivierten Sprachen ist bei der Zuordnung von Optionen zu Produkten nicht gegeben. Sollten in der Tabelle products_options Spracheeinträge fehlen liegt ohnehin eine Inkonsistenz der Inhalte der betroffenen DB-Tabelle vor.

Gruß,
noRiddle

[noRiddle]

Was ich hier gemeldet habe ist Unsinn. Weiß leider nicht mehr was ich da gedacht habe oder ob ich etwas verwechselt habe.
Sorry for that.
Ticket kann als "völliger Blödsinn" geschlossen werden.

Gruß,
noRiddle

[noRiddle]

Nachdem ich nun erneut darauf gestossen bin muß ich revidieren und das Ticket sollte wieder aktiviert werden.
Es ist definitiv nicht nur völlig unnötig mit der Tabelle products_options zu JOINen,
sondern auch unsinnig.
Anstatt diesem bisherigen

      $products_attributes_query = xtDBquery("SELECT count(*) AS total_a,
                                                     count(IF(patrib.options_values_price > 0, 1, null)) as total_p 
                                                FROM ".TABLE_PRODUCTS_OPTIONS." popt
                                                JOIN ".TABLE_PRODUCTS_ATTRIBUTES." patrib
                                                     ON patrib.options_id = popt.products_options_id
                                                        AND popt.language_id = '".(int) $_SESSION['languages_id']."'
                                               WHERE patrib.products_id = '".(int)$pID."'");

reicht dies völlig aus:

      $products_attributes_query = xtDBquery("SELECT count(*) AS total_a,
                                                     count(IF(options_values_price > 0, 1, null)) as total_p 
                                                FROM ".TABLE_PRODUCTS_ATTRIBUTES." 
                                               WHERE products_id = '".(int)$pID."'");

Gruß,
noRiddle

[Gerhard Waldemair]

Wenn wir das so machen wie vorgeschlagen, ist keine Prüfung mehr vorhanden ob es auch Optionen gibt in entsprechender Sprache gibt.

So wie es jetzt ist, ist es aber auch nicht ausreichend.

Die Frage ist ob hier eine Abfrage nach Übersetzungen notwendig ist.

[noRiddle]

Wie könnte es geschehen, daß es Optionen nicht in der entsprechenden Sprache gibt ?
Wenn eine Sprache später angelegt wurde und die Optionen nicht in der neuen Sprache gespeichert sind ?

Wenn man das abfangen wollen würde müsste man nicht nur hier weiter ausholen sondern auch an vielen anderen Stellen im System wo ein solches Problem mit fehlenden Werten in einer oder mehreren Sprachen vorkommen könnte.

Eine Prüfung "ob es auch Optionen gibt in entsprechender Sprache gibt" wird allein an dieser Stelle zu nichts führen. Was sollte es denn für Konsequenzen haben wenn nicht ?
Diese müssten sich ja dann an den (zwei) Stellen wo die Methode bislang angewendet wird auswirken.

Ich denke im Moment, mangels besserer Idden, daß man das erstmal so lassen und sich auf eine konsistente DB verlassen muß.

Gruß,
noRiddle

[Gerhard Waldemair]

Ich behaupte mal ganz frech, dass alle anderen Abfragen so gestaltet sind, dass nur das dargestellt wird, was auch in der entsprechenden Sprache gepflegt ist. Manchmal wird das auch ganz bewusst verwendet um Artikel in DE aber nicht ein EN anzuzeigen.

Ein Problem das ich sehe:
ich lege einen Artikel in den Warenkorb mit Attribute und stelle dann die Sprache um weil ich sehe, dass ich doch auf EN umstellen kann.

Plötzlich hat der Artikel keine Attribute mehr oder noch viel schlimmer, der Artikel verschwindet aus dem Warenkorb.

[noRiddle]

Verstehe vollkommen. Aber das kannst du ja nicht mit der Funktion getAttributesCount() abfangen.

Gruß,
noRiddle

[Gerhard Waldemair]

In 15176:

fix #2377 - check only products_attributes for attributes due to performance