Contao löscht Datensätze

[Wusch]

Hallo,

ich entwickle gerade ein kleines Modul (Konfigurator) zum Testen. Es gibt in dem Modul Archive, Produkte, Kategorien und Optionen. Ich habe das im DCA mit Mode 1 für Archive und Mode 4 für den Rest gelöst. Verbunden ist alles über die Option ptable. Funktioniert auch fast einwandfrei.
Irgendwann (konnte den Zeitraum noch nicht eingrenzen) wenn ich dann auf ein Archiv gehe und die Produkte bearbeiten möchte, wurden diese einfach gelöscht. Kategorien und Optionen sind noch vorhanden. Kennt jemand das Problem oder weiß einen Lösungsansatz?

Contao Version: 3.2.3

[Wusch]

Wah gefunden, ein DCA einer anderen Tabelle bei der eine falsche ctable eingetragen war. Man sollte bei Copy & Paste aufpassen.

[theobald]

na ich meine: Auch bei einer falschen ctable sollte Contao (bei mir 3.2.3) mit dem Löschen nicht so schnell sein! Ich habe ein ähnliches Problem aktuell unter Beobachtung (weiss aber nicht genau warum dieses Verhalten implementiert wurde), wobei vor jedem Aufruf einer Auflistung mit verknüpften Tabellen folgendes SQL-Statement abgesetzt wird:

Fatal error: Uncaught exception Exception with message Query error: Unknown column 'tl_events.pid' in 'where clause' (DELETE FROM tl_events WHERE NOT EXISTS (SELECT * FROM tl_owner WHERE tl_events.pid = tl_owner.id)) thrown in system/modules/core/library/Contao/Database/Statement.php on line 282

#0 system/modules/core/library/Contao/Database/Statement.php(253): Contao\Database\Statement->query()
#1 system/modules/core/library/Contao/Database.php(189): Contao\Database\Statement->execute()
#2 system/modules/core/drivers/DC_Table.php(3154): Contao\Database->execute('DELETE FROM tl_...')
#3 system/modules/core/drivers/DC_Table.php(333): Contao\DC_Table->reviseTable()
#4 system/modules/core/classes/Backend.php(429): Contao\DC_Table->showAll()
#5 contao/main.php(136): Contao\Backend->getBackendModule('parishes')
#6 contao/main.php(287): Main->run()
#7 {main}

Nur durch diesen Fehler bin ich darauf aufmerksam geworden, wer in meinen Tabellen die Datensätze löscht. Die waren immer weg und ich hatte keine Löschoperation irgendwo gesehen.

Warum hier in einer verknüpften Tabelle Datensätze glöscht werden, ist mir nicht klar! Man könnte Sie ja unberührt lassen...

[ciaobello]

Warum hier in einer verknüpften Tabelle Datensätze glöscht werden, ist mir nicht klar! Man könnte Sie ja unberührt lassen...

Könnte durchaus ne Leiche im Keller sein die man ständig wieder zu vergraben versucht ?! Hier mal ein paar Zitate welche letztes Jahr gemacht wurden:

Moderation: Thema ausgegliedert aus diesem Thread um nicht zwei Themen zu vermischen.

Ich habe es zwar schon so oft geschrieben, aber hier sind noch einmal ein paar der Punkte die an Contao 3 fürn Eimer sind.

* Falsche Verwendung von Namespaces
* Autoloader verwendet kein PSR Standard
* Cache kopiert einfach ganze Dateien ineinander welches zu PHP Fehlern durch "cannot redeclare" führt
* Pfad-Mapping funktioniert auf dne meisten Shared-Hostern nicht richtig, indexierung schlägt oft Fehl und ist stellenweise inkonsistent
* Models führen zu Datenverlust!!!!!!!!!
....

Ich möchte noch Kurz auf den letzten Punkt eingehen, die Models. Weil du ja meintest das sieht alles sehr sauber und ordentlich aus. Kleines Beispiel dazu welches mich beim ersten Debuggen fast 2 Tage gekostet hat, da es in absolutem brainfuck ausartet:

Contao 3 hat Models eingeführt, welche jedoch nur optional sind. sprich, es ist nachwievor noch erlaubt und wird auch gemacht, das daten via plain query modifiziert werden. Profis sehen schon worauf ich hinaus will. Nehmen wir mal die tl_member Tabelle her. Du hohlst du dir daten eines Mitglieds als $objMemberModel und arbeitest damit. Danbn hohlt sich ein anderes Modul die daten via "SELECT * FROM tl_member WHERE id=?" . Jetzt hast du 2 mal den gleichen Datensatz. Du änderst das Model ab und machst $objMemberModel->save(); Das SChreibt dir dir Daten zurück in die Datenbank. Dein Query beinhaltet aber immer noch die alten Daten und killt beim zurückschreiben alle daten des Models. Ergo ist die änderung weg. Wenn du jetzt aber als Query sagst, ich lade die daten noch mal neu, so fickt dich der Query cache, weil du erst wieder den alten Datensatz bekommst. Ergo, du hast wieder einen Datensatz verloren. Dann wirds aber lustiger, ein Model ist nicht "unique". Das heißt, wenn 2 Extensions das gleiche Model holen, werden von Contao 3 2 models erstellt, welche beide bei einem Update aber NICHT gesynct werden. Also wenn $obj1->save() macht und dann $obj2->save(); killt $obj2 die Daten aus $obj1. Ergo, schon wieder Datenverlust.

Ich habe diesen bug bereits so oft erklärt, dass es jetzt eigentlich jeder wissen sollte. Auch Leo Feyer weiß von diesem Bug, sieht es aber nicht als Problematisch an. Er meinte nur: "müssen wir uns mal anschauen". Hä, Datenverlust? Ja ne, hat ja Zeit ...

Dann kommen natürlich noch so dinge hinzu, das Contao 3 permanent dinge Nacharmt welche viel besser in der SPL drin sind. Bsp simulieren Collections in Contao 3 das iterieren über den Datensatz, jedoch implementieren sie nicht "iteratable". Warum? Keine ahnung ...

....

[DampfHans]

Oh ja... mit DC_Table.reviseTable() hatte ich auch schon meinen Spaß! Durch diese Funktion führen DCA-Fehler zum Löschen von Datensätzen. Hier rächt sich, das Contao alle SQL-Mechanismen zur referentiellen Integerität ignoriert (ignorieren muss...) und nur in PHP nachahmt - sozusagen referentielle Integrität für Arme.

Besonders "witzig" ist auch das Löschen aller Datensätze mit tstamp = 0. Wenn man (so wie ich) in einer eigenen Erweiterung Datensätze erzeugt und tstamp nicht setzt, dann kann man sich schon längere Zeit darüber wundern warum diese Datensätze immer wieder verschwinden.

Da reviseTable() Datensätze löscht, die eigentlich gar nicht existieren dürften wäre der eine oder andere Errorlog eigentlich sinnvoll - dann wäre man wenigstens vor- bzw. nachgewarnt. Noch besser wäre es m.E. wenn reviseTable gar nichts löschen sondern ein Exception auslösen würde.

[markocupic]

Oh ja... mit DC_Table.reviseTable() hatte ich auch schon meinen Spaß! Durch diese Funktion führen DCA-Fehler zum Löschen von Datensätzen. Hier rächt sich, das Contao alle SQL-Mechanismen zur referentiellen Integerität ignoriert (ignorieren muss...) und nur in PHP nachahmt - sozusagen referentielle Integrität für Arme.

Schade, dass man mit Contao nicht die vollen Möglichkeiten einer mysql Datenbank ausschöpfen kann.
Wäre schön, wenn Contao in Zukunft echte referentielle Integrität (innodb) ermöglichen würde. Beim Versuch Tabellen mit echter referentieller Integrität zu verknüpfen endet das Vorhaben spätestens dann in einem Fehler, wenn man im Backend einen neuen Datensatz einer anlegen möchte. Der Datensatz wird nämlich temporär in der db angelegt, natürlich sind zu Beginn die Felder, die mit einem Index versehen sind, noch leer, das dürfen sie aber nicht!!! Der Feldinhalt referenziert hier die id eines Datensatzes in der Elterntabelle. Genau hier steht mysql auf die Hinterbeine und bricht mit einem Fehler ab.

Dies nur als Anmerkung...

Bis dies möglich wird, muss wohl weiter mit dem Umweg über die ondelete_callbacks gearbeitet werden.
Lg Marko