Heute bekam ich ein Problem auf den Tisch, wo es darum geht das eine Kategorie URL ständig ein _1 angehängt bekommt wenn diese eine Änderung hat oder es einen Komplettabgleich gibt obwohl dieses nicht erforderlich ist.
Die Ausgangssituation ist folgende:
der Shop ist mehrsprachig, die cSeo Url ist in allen Sprachen gleich, so das der Shop die Url vermutlich mal durchnummeriert hat.
Die obere URL ist die deutsche Sprache, wenn ich jetzt einen Abgleich mache und in der Kategorie etwas geändert habe, dann löscht der Shop diese Einträge kKategorie=120 ja aus der Datenbank und erstellt diese Einträge dann neu.
Das bedeutet jetzt, das wenn checkSeo() kommt, er theoretisch, Hula-Hoop nicht finden sollte und die gewünschte Url so wie gewünscht zurückgeben sollte.
Das passiert aber nicht, es wird wenn die Kategorie geupdated wird, immer Hula_Hoop_1 zurückgegeben.
Ich glaube das die Funktion checkSeo überarbeitet werden müsste.
Zum einen ist der unterstrich ein x-beliebiges Zeichen, wodurch wenn ich nach 'Hula-Hoop_%' suche auch Treffer gefunden werden die Hula-Hoop-Turnschuh, Hula-Hoop-Turnschuh_7 usw. heißen.
Ein Unterstrich müsste also eigentlich escaped werden um sicher zu gehen das es als Unterstrich behandelt wird. (Stand MySQL 5.7) https://dev.mysql.com/doc/refman/5.7/en/pattern-matching.html
Zum anderen frage ich mich, warum diese Schleife zur Namensfindung grundsätzlich aufgerufen wird, das kostet doch unnötig Performance, warum gibt es nicht zuerst eine Abfrage ob es genau diese Url schon gibt.
Die Funktion führt also bei einem Komplettabgleich mit 300 Kategorien, 300 mal ( je Sprache) diese SQL Abfrage aus :
Aus meiner Sicht wäre ein vorheriges direktes Prüfen der Url bestimmt nicht so fehleranfällig und würde den SQL Server weniger stressen.
Die Ausgangssituation ist folgende:
der Shop ist mehrsprachig, die cSeo Url ist in allen Sprachen gleich, so das der Shop die Url vermutlich mal durchnummeriert hat.
Die obere URL ist die deutsche Sprache, wenn ich jetzt einen Abgleich mache und in der Kategorie etwas geändert habe, dann löscht der Shop diese Einträge kKategorie=120 ja aus der Datenbank und erstellt diese Einträge dann neu.
Das bedeutet jetzt, das wenn checkSeo() kommt, er theoretisch, Hula-Hoop nicht finden sollte und die gewünschte Url so wie gewünscht zurückgeben sollte.
Das passiert aber nicht, es wird wenn die Kategorie geupdated wird, immer Hula_Hoop_1 zurückgegeben.
Ich glaube das die Funktion checkSeo überarbeitet werden müsste.
Zum einen ist der unterstrich ein x-beliebiges Zeichen, wodurch wenn ich nach 'Hula-Hoop_%' suche auch Treffer gefunden werden die Hula-Hoop-Turnschuh, Hula-Hoop-Turnschuh_7 usw. heißen.
Ein Unterstrich müsste also eigentlich escaped werden um sicher zu gehen das es als Unterstrich behandelt wird. (Stand MySQL 5.7) https://dev.mysql.com/doc/refman/5.7/en/pattern-matching.html
Zum anderen frage ich mich, warum diese Schleife zur Namensfindung grundsätzlich aufgerufen wird, das kostet doch unnötig Performance, warum gibt es nicht zuerst eine Abfrage ob es genau diese Url schon gibt.
Die Funktion führt also bei einem Komplettabgleich mit 300 Kategorien, 300 mal ( je Sprache) diese SQL Abfrage aus :
Code:
SET @IKEY := 0;
select oseo.newSeo
FROM (
SELECT CONCAT('Hula-Hoop', '_', @IKEY:=@IKEY+1) newSeo, @IKEY nOrder
FROM tseo AS iseo
WHERE iseo.cSeo LIKE 'Hula-Hoop%'
AND iseo.cSeo RLIKE '^Hula-Hoop(_[0-9]+)?$'
) AS oseo
WHERE oseo.newSeo NOT IN (
SELECT iseo.cSeo
FROM tseo AS iseo
WHERE iseo.cSeo LIKE 'Hula-Hoop_%'
AND iseo.cSeo RLIKE '^Hula-Hoop_[0-9]+$'
)
ORDER BY oseo.nOrder
LIMIT 1Aus meiner Sicht wäre ein vorheriges direktes Prüfen der Url bestimmt nicht so fehleranfällig und würde den SQL Server weniger stressen.
