Seite 1 von 1

cat_tree / strRemakeTreeTable Problem

Verfasst: Mi 23. Nov 2005, 12:54
von knb
betr eine Testinstallation

Bei mir hat beim Verschieben von Kategorien offenbar ein Script verrückt gespielt und in tabelle cat_tree 2400 hochredundante datensätze eingefügt.

Kategorie - Navigationsbaum wurde für betroffene Mandanten nicht mehr angezeigt, weder im frontend noch im Backend.

Habe strRemakeTreeTable() aus functions.str.php per PHP script aufgerufen.

Das PHP script das die Funktion aufruft hatte einen Timeout. Tabelle war immer noch 2400 DS lang nach dem Timeout. Es gab auch keine Errorlog einträge.


Ich habe die Tabelle cat_tree mit phpmysqlAdmin geleert und dann nochmals strRemakeTreeTable() aus functions.str.php aufgerufen.

Scheint die Tabelle wieder neu aufgebaut zu haben, jetzt sind nur noch plausible 290 Datensätze drin.

Meine Frage:
wird es anderswo Probleme geben wenn die Tabelle cat_tree manuell geleert wird, UND strRemakeTreeTable ausgeführt wird, oder wird vom manuellen Leeren dieser Tabelle generell abgeraten ?

(strRemakeTreeTable MUSS nach dem Leeren mindestens einmal ausgeführt werden, sonst wird es probleme geben ;-) )

Re: cat_tree / strRemakeTreeTable Problem

Verfasst: Mi 23. Nov 2005, 14:03
von emergence
knb hat geschrieben:wird es anderswo Probleme geben wenn die Tabelle cat_tree manuell geleert wird, UND strRemakeTreeTable ausgeführt wird, oder wird vom manuellen Leeren dieser Tabelle generell abgeraten ?
probleme wird es ziemlich sicher keine geben...
abraten ? nein warum ? alles was funktioniert ist erlaubt ;-)
gibts ein problem -> selbst schuld kein mitleid (besonders dann nicht wenn das jemand ohne backup versucht)

Verfasst: Mi 23. Nov 2005, 16:07
von knb
Ich fragte weil ich auf die schnelle nur halb verstanden hatte was strRemakeTreeTable macht.

Es hätte ja auch sein können dass die Funktion mit einer ganz leeren Tabelle nichts anfangen kann, bzw in anderen Tabellen dann auch noch was gelöscht werden muss...
so was in der Art wollte ich nur in Erfahrung bringen.

Verfasst: Mi 23. Nov 2005, 16:11
von emergence
also in den anderen con_cat tabellen würd ich auf keinenfall was löschen...
so wirklich genau hab ich mir die funktion aber noch nicht angesehen, da sie eigentlich bei mir immer ganz gut funktioniert hat...

Verfasst: Mi 23. Nov 2005, 16:27
von knb
Die Funktion macht am Anfang das hier
(snip aus functions.str.php)

Code: Alles auswählen

        $sql = "DELETE FROM ".$cfg["tab"]["cat_tree"];                    // empty 'cat_tree'-table
        $db->query($sql);

        $sql = "DELETE FROM ".$cfg["tab"]["cat"]." WHERE idcat='0'";
        $db->query($sql);

        $sql = "DELETE FROM ".$cfg["tab"]["cat_lang"]." WHERE idcat='0'";
        $db->query($sql);

leider fehlen Kommentarzeilen was die zweiten und dritten DELETEs machen -- der erste Kommentar dagegen ist ziemlich überflüssig :-)

naja, is erstmal egal, Frage beantwortet, aber bei diesen ganzen Kategoriebaum-Funktionen in functions.str.php drängt sich der Gedanke auf :

Schade dass mysql 4 keine transaktionen unterstützt.

Wenn man nämlich umfangreiche Äste verschiebt, ist ziemlich wahrscheinlich dass mal was unvollständig ausgeführt wird.

Und das malheur dann zu reparieren kann einen schon ein paar Tage beschäftigen . :?

Verfasst: Mi 23. Nov 2005, 16:29
von emergence
ach so das zweite und das dritte statement haben nur den sinn und zweck, das es zu keine endlosschleife kommen kann...
aufgrund des lock table problems wurde manchmal in den beiden tabellen ein eintrag mit idcat 0 vorgenommen... und da hat es immer gekracht...