--- title: "Kleine Frage zu @cascade" url: "https://www.typo3.net/d/117172-kleine-frage-zu-at-cascade" source: "typo3.net" tags: ["Extensions","Extbase","Frage"] created: "2014-01-21" last_reply: "2014-02-05" replies: 8 solved: true page: 1 pages: 1 lang: "de" --- # Kleine Frage zu @cascade Extensions › Extbase · 8 Antworten · gelöst · gestartet 2014-01-21 ## Frage **Unbekannter Benutzer** · 2014-01-21 · [Beitrag #1](https://www.typo3.net/d/117172-kleine-frage-zu-at-cascade/1) Ich hätte mal eine kurze Verständnisfrage zu @cascade. Das grundsätzliche Prinzip ist mir klar: Wenn ich ein Objekt "Firma" habe und Objekte "Mitarbeiter", die in einer 1:n-Beziehung zueinander stehen, werden alle Mitarbeiter einer Firma gelöscht, sobald ich die Firma lösche. Wie verhält sich @cascade nun aber, wenn Firma und Mitarbeiter in einer n:m-Beziehung zueinander stehen? (Ein Mitarbeiter kann in mehreren Firmen arbeiten, weshalb eine Zuordnungstabelle "mitarbeiter_firma" benötigt wird). Werden mit @cascade in diesem Fall nur die Datensätze in der Zuordnungstabelle gelöscht (was für mich Sinn machen würde) oder werden auch die Mitarbeiter-Datensätze gelöscht (was keinen Sinn machen würde)? Danke schon mal für die Antwort :) ## Beste Antwort **harald1972** · 2014-01-22 · [Beitrag #2](https://www.typo3.net/d/117172-kleine-frage-zu-at-cascade/2) Hallo, ich klink mich hier mal ein. > Wenn ich ein Objekt "Firma" habe und Objekte "Mitarbeiter", die in einer 1:n-Beziehung zueinander stehen, werden alle Mitarbeiter einer Firma gelöscht, sobald ich die Firma lösche. Soviel zur Theorie. Ich hab hier grad so einen Fall, bei dem das aber nicht funktioniert. ```php /** * @var \TYPO3\CMS\Extbase\Persistence\ObjectStorage<\path\to\my\Child> * @cascade remove */ protected $children; ``` Nach delete (mit der deleteAction) will ich das in der DB überprüfen... Das Elternobjekt erhält deleted="1". Beim Kindobjekt ändert sich nichts. Ich hab grad leider keinen Schimmer, woran das liegen könnte, deshalb sorge ich in der deleteAction der Eltern selbst für das remove($child); Also erweitere ich die Frage um: Was muss man beachten, damit sich **@cascade remove** auch so verhält, wie erwartet? Oder was kann man dabei alles falsch machen? ## Antworten ### [#2](https://www.typo3.net/d/117172-kleine-frage-zu-at-cascade/2) · harald1972 · 2014-01-22 · Beste Antwort (Text siehe oben unter „Beste Antwort“.) ### [#3](https://www.typo3.net/d/117172-kleine-frage-zu-at-cascade/3) · Unbekannter Benutzer · 2014-01-24 Nach zwei Versuchen in Typo3 6.1 (Typo3 6.2 beta4 konnte nicht getestet werden, da hier der Extension-Builder gerade nicht funktioniert) konnte ich etwas mehr Klarheit zum aktuellen Stand in die Sache bringen. Die Versuche beziehen sich auf oben genanntes Beispiel mit Firma und Mitarbeitern, wobei die Datensätze jeweils im Typo3-Backend angelegt wurden. Nun zum Ergebnis der Versuche: **Versuch 1: 1:n-Beziehung zw. Firma und Mitarbeiter** Die Mitarbeiter wurden sowohl beim Löschen über die Lösch-Funktion im Typo3-Backend auf "deleted" gesetzt, als auch über das normale Löschen im Controller. Mein Code zum Löschen-Test im Controller: ```php $company = $this->companyRepository->findByUid(1); $this->companyRepository->remove($company); ``` **Versuch 2: n:m-Beziehung zw. Firma und Mitarbeiter** Die n:m-Beziehung wurde über den Extension-Builder so angelegt, dass bei den Firmen die Beziehung "Mitarbeiter" (members) eingefügt wurde und diese als n:m-Beziehung zum Mitarbeiter-Objekt angelegt wurde. Das Objekt Mitarbeiter (member) hat aber keine Beziehung oder Eigenschaft "Firmen" (companies) erhalten, da der Extension Builder hier eine zweite Zuordnungstabelle angelegt hätte... Die Mitarbeiter wurden weder beim Löschen der Firma über die Lösch-Funktion im Typo3-Backend noch über das normale Löschen im Controller (mit oberen Code) aus der Zuordnungstabelle entfernt. Es bleiben hier also "unsaubere" Datensätze in der Zuordnungstabelle zurück zu Firmen, die eigentlich nicht mehr existieren. **Daraus resultierende Probleme / Fragen:** Bei einer n:m-Beziehung müssen nach aktuellem Stand also die Kinder explizit selbst gelöscht werden. Dazu hatte ich folgenden Code versucht, damit ich über das "Eltern-Objekt" gehen kann und nicht davon unabhängig ins Mitarbeiter-Repository muss: ```php $company = $this->companyRepository->findByUid(1); $members = $company->getMembers(); $members->removeAll($members); $this->companyRepository->update($company); $this->companyRepository->remove($company); ``` Der Code hat mir aber leider nur einen Datensatz aus der Zuordnungstabelle gelöscht und das war der, bei dem der Mitarbeiter ausschließlich in dieser Frma gearbeitet hat und in keiner anderen. Es scheint bei diesem Code also so zu sein, dass das Löschen geblockt wird, wenn ein Mitarbeiter eine Beziehung zu einer weiteren Firma hat - was absolut keinen Sinn macht in einer Zuordnungstabelle. Ich könnte nun natürlich anfrangen, die Variable $members auf dem oberen Code einzeln zu durchlaufen und aus dem Mitarbeiter-Repository zu löschen, aber das ist ja eigentlich nicht der Sinn der Sache - davon abgesehen wird dann ja der MITARBEITER gelöscht und nicht der Datensatz aus der Zuordnungstabelle. Deshalb lautet hier meine Frage: Wie entferne ich die Zuordnung der Mitarbeiter hier korrekt aus der Zuordnungstabelle ohne den Mitarbeiter selbst zu löschen? Und dann habe ich in diesem Zug noch eine weitere Frage. Und zwar ist eine Beziehung ja aus zwei Richtungen zu betrachten. Zum einen will ich in einer Firma die Eigenschaft "Mitarbeiter" (members) haben, die als StorageObject alle Mitarbeiter enthält. Zum anderen will ich das umgedreht auch im Mitarbeiter-Objekt mit den Firmen haben. Der Extension-Builder erstellt die Eigenschaft members aber nur im Firmen-Objekt, nicht aber "companies" im Mitarbeiter-Objekt. Wenn ich im Extension-Builder eine weitere n:m-Beziehung mit der Eigenschaft "companies" vom Mitarbeiter-Objekt aus anlege, erstellt der Extension-Builder logischerweise eine zweite Zuordnungstabelle. Ich habe versucht das manuell zu lösen und auch die TCA entsprechend angepasst, damit ich auch beim Mitarbeiter die Firmen auswählen kann, aber das erzeugt einen Fehler beim Abspeichern des Mitarbeiters. Wie legt man also korrekt (im Extension-Builder oder manuell) eine n:m-Beziehung an, die ich aus beiden Richtungen betrachten kann? Allgemein habe ich langsam das gefühl, dass extbase nicht wirklich zu Ende gedacht bzw. nicht in der Praxis an verschiedenen Problemstellungen getestet wurde. Mein Fazit zum aktuellen Standpunkt - Idee: top, Umsetzung: flopp... Ich hoffe das wird noch besser... ### [#4](https://www.typo3.net/d/117172-kleine-frage-zu-at-cascade/4) · Unbekannter Benutzer · 2014-01-29 Hat keiner eine Idee zu meinen beiden Fragen im letzten Teil bezogen auf meinen letzten Post?: (Wie entferne ich die Zuordnung der Mitarbeiter hier korrekt aus der Zuordnungstabelle ohne den Mitarbeiter selbst zu löschen? / Wie legt man also korrekt eine n:m-Beziehung an, die ich aus beiden Richtungen betrachten kann?) Ich kann mir eigentlich nicht vorstellen, dass diese Problematik so außergewöhnlich ist oder schwer zu lösen. Ich habe es leider trotzdem noch nicht selbst hinbekommen und auch noch keine passende Lösung dazu gefunden... Ich bin für alle Ideen / Ansätze offen :-) ### [#5](https://www.typo3.net/d/117172-kleine-frage-zu-at-cascade/5) · harald1972 · 2014-01-31 Moinmoin, ich hab jetzt mal rumgetestet... (mein erster post ist hinfällig... ich hatte einen Error-40 ;) ) jetzt aber zu Susi... > Die Mitarbeiter wurden weder beim Löschen der Firma über die Lösch-Funktion im Typo3-Backend noch über das normale Löschen im Controller (mit oberen Code) aus der Zuordnungstabelle entfernt. > Es bleiben hier also "unsaubere" Datensätze in der Zuordnungstabelle zurück zu Firmen, die eigentlich nicht mehr existieren. Gleich vorneweg: Ich betrachte hier nichts und bearbeite nichts übers BE. Das muss alles mit dem fluid/extbase/php-Code laufen. Und dann noch eine Gegenfrage: Wenn du eine Entität "löschst", wird dann deleted=1 ? oder machst du ein echtes DELETE FROM DB_table? Denn so ein (deleted) Objekt steht ja immer noch in der DB und hält alle Beziehungen aufrecht. Konkret (bei dir): Die gelöschte Company hat immer noch die Anzahl members in der members-Spalte, wie es in der MM-Tabelle Zuordnungen hat. Deine MM-Tabelle (tx_deineext_company_member_mm) müsste imho genau 4 Spalten haben: uid_local, uid_foreign, sorting, sorting_foreign. Schon aus dem Tabellennamen ist ersichtlich, dass sie kein Teil der Domäne ist. (vgl. tx_deineext_domain_model_company) Das von dir beschriebene Verhalten ist korrekt, insofern die MM-Einträge durch attach/detach erzeugt und gelöscht werden. Wenn die Firma pleite geht, ist das (noch nicht) der Tod des Mitarbeiters. Selbst wenn der Mitarbeiter in keiner einzigen Firma mehr ist (und eigentlich auch pleite ist), ist er nicht tot und auch wenn die Firma plötzlich weg ist, hat sie (theoretisch) immer noch ihre Mitarbeiter. Das gleiche gilt für Beziehungen unter Entitäten... Wenn ich z.B. eine Firma anleg, und dann 5 Mitarbeiter dazu; dann lösche ich die Firma und (bei cascade remove) werden auch die 5 Mitarbeiter gelöscht (deleted=1). Allerdings bleibt die Spalte members in der gelöschten Company auf 5, obwohl diese 5 Members auch auf deleted=1 stehen. Auch die Spalte company der gelöschten Members verweist noch auf die gelöschte Company. Diese noch bestehenden Einträge in der MM-Tabelle sind also nur unsauber, weil du sie nicht entfernt hast ;) Weil die Beziehung eben immer noch besteht. (Vgl.: ich bin immer noch der Sohn meines Vaters, auch wenn dieser tot ist) > Wie entferne ich die Zuordnung der Mitarbeiter hier korrekt aus der Zuordnungstabelle ohne den Mitarbeiter selbst zu löschen? Wie oben schon erwähnt: mit detach, also ungefähr so (in deiner \Domain\Model\Company.php) ```php /** * @param \...\Domain\Model\Member $member * @return void */ public function removeMember(\...\Domain\Model\Member $member) { $this->members->detach($member); } ``` So sollte es zumindest für einzelne funktionieren. Jetzt kommt der Punkt, an dem ich auch schon Stunden verbracht habe... das klappt bei einzelnen Beziehungen zum entfernen. Aber für alle auf einmal klappt das bei mir nicht. Ich habs (wie du oben) mit removeAll(...) versucht, ich habs sogar mit einer foreach-Schleife versucht und darin jedes einzelne remove direkt aufgerufen. Ich hab dem Controller gesagt, er soll löschen und ich habs dem Model gesagt. Das Problem, das ich festgestellt habe ist, dass nur jedes zweite mm-Element gelöscht wird, genauer gesagt jedes Zweite bleibt stehen. Beim ersten removeAll() fallen die Elemente mit sorting = 1,3,5,7,... während 2,4,6,8,... bleiben Beim zweiten removeAll() bleiben noch 4,8,... Dieser Bug scheint (wenigstens bei mir) genau so jedesmal reproduzierbar zu sein. > Wie legt man also korrekt (im Extension-Builder oder manuell) eine n:m-Beziehung an, die ich aus beiden Richtungen betrachten kann? Ich selbst habe bisher versucht, diese TYPO3-MM-Tabellen zu vermeiden, weil ich die genaue Technik dahinter einfach nicht verstanden hab und weil man schon in DB-Grundlagen lernt, jede M:N-Beziehung in eine entsprechende Tabelle auszulagern - also hab ich das auch immer selbst gemacht. Also hab ich mir eigene Tabellen angelegt, die die gewünschte Verbindung abbilden. Ein Mitarbeiter hat doch bestimmt einen Vertrag. Für deinen Fall wäre also (im ExtensionBuilder) ein Objekt anzulegen (Entity), mit je einer n:1 Beziehung zu einer Company und zu einem Member. Sagen wir, diese Tabelle/Objekt soll "contract" heissen. Dann müssen Company + Member jeweils noch eine 1:n Beziehung (contracts) zu dieser Tabelle haben. Jetzt brauch ich erstmal nen Kaffee, dann sortier ich meine Gedanken und geh weiter auf Wanzenjagd ;) Gruß Harald ### [#6](https://www.typo3.net/d/117172-kleine-frage-zu-at-cascade/6) · Unbekannter Benutzer · 2014-01-31 Hallo Harald, vielen Dank für deine ausführliche Antwort. **Erstmal zu deiner ersten Nachfrage:** Bei der 1:n-Beziehung ist es so, wie du sagstest: die Mitarbeiter wurden auf deleted=1 gesetzt und die Anzahl der Mitarbeiter in dem Datensatz der gelöschten Firma bleibt gleich. Bei der n:m-Beziehung wird zumindest der eine Datensatz richtig aus der Zuordnungstabelle gelöscht (also entfernt) - der Datensatz in der Mitarbeiter-Tabelle bleibt bestehen (was ja auch korrekt ist). Hier stimmt die Anzahl der Mitarbeiter in der Firma nach dem Löschen mit denen in der Zuordnungstabelle überein (wird also um 1 weniger, da eine Zuordnung aus der Datenbank gelöscht wurde). **Zu attach/detach:** Du hast Recht, wenn ich einen einzelnen Mitarbeiter via detach bei der n:m-Beziehung aus der Firma entferne, wird sowohl der Datensatz in der Zuordnungstabelle korrekt gelöscht, als auch die Anzahl der Mitarbeiter im Firmendatensatz runter gezählt. Wenn ich die Mitarbeiter aber in einer Schleife mit detach entferne, tritt bei mir das selbe Phänomen auf, wie bei dir: es wird nur jeder zweite Datensatz aus der Zuordnungstabelle gelöscht. Da dies also offensichtlich ein Bug ist, habe ich mich auf die Suche nach bestehenden Bug-Reports gemacht und siehe da - hier ist die Lösung zu dem Problem: Der Code zum Löschen der Mitarbeiter in einer n:m-Beziehung in dem Firmen-Controller muss also wie folgt aussehen: ```php $company = $this->companyRepository->findByUid(5); $members = $company->getMembers(); $memberClone = clone $members; $members->removeAll($memberClone); $this->companyRepository->update($company); $this->companyRepository->remove($company); ``` **Zu n:m-Beziehung aus zwei Seiten betrachten:** n:m-Beziehungen lassen sich leider nicht immer vermeiden und sind ja eigentlich auch eine völlig normale Sache bei der Datenbankmodellierung, wenn es korrekt über eine Zuordnungstabelle gelöst ist. Das kann Typo3 mit extbase ja auch sehr schön - aber eben nur von einer Seite aus... D.h. nach deinem Vorschlag dürfte ich die Zuordnungstabellen nicht automatisch aus einer n:m-Beziehung über Typo3 bzw. den Extension-Builder erstellen lassen, sondern ich müsste die Zuordnungstabelle als eigenes Objekt anlegen (z.B. Contract) und dann die Firma und die Mitarbeiter per 1:n-Beziehung zu "Cotract" verweisen lassen? Hm... das hört sich für mich nach ziemlich viel Aufwand und vor allem nach ziemlich viel zusätzlichen Objekten an, wenn man viele Zuordnungstabellen benötigt... Da mus sich noch mal drüber schlafen :-) Ich habe nochmal versucht die andere Betrachtungsweise (Firmen, die einem Mitarbeiter zugeordnet sind) zusätzlich selbst einzubauen. Dabei habe ich den Code, den der Extension-Builder im Company-Model angelegt hat um die members (Mitarbeiter) zu verwalten, in mein Member-Model übernommen und entsprechend angepasst. Gleiches gilt auch für das TCA der Members (hier habe ich die Eigenschaft "companies" ergänzt mit den entsprechenden Änderungen). Auf den ersten Blick funktioniert es auch, dass ich im BE beim Bearbeiten der Mitarbeiter eine Firmenauswahl erhalte und die Zuordnung in der Zuordnungstabelle gespeichert wird. Der Haken: die Zuordnungstabelle heißt tx_test_company_member_mm - entsprechend muss in die Spalte uid_local die uid der Firma und in uid_foreign die uid des Mitarbeiters. Wenn ich eine Firma bearbeite und einen Mitarbeiter hinzufüge, funktioniert das auch. Wenn ich aber einen Mitarbeiter bearbeite und eine Firma hinzufüge, speichert Typo3 in uid_local die uid des Mitarbeiters, was natürlich genau falsch herum ist. Wenn ich dieses Problem beheben kann, kann ich theoretisch die Betrachtung aus zwei Seiten für n:m-Beziehungen realisieren ohne die Zuordnungstabelle als eigenes Objekt anlegen zu müssen. Ich vermute mal, dass man in der Configuration/TCA/Member.php irgendwo in der Definition der Eigenschaft "companies" angeben kann, dass die uid des Mitarbeiters in der Spalte "uid_foreign" gespeichert werden soll. Hast du hier vielleicht eine Idee, wie ich das hinbekomme? Meine Definition für "companies" im TCA der Member sieht aktuell wie folgt aus: ```php 'companies' => array( 'exclude' => 0, 'label' => 'LLL:EXT:test/Resources/Private/Language/locallang_db.xlf:tx_test_domain_model_member.companies', 'config' => array( 'type' => 'select', 'foreign_table' => 'tx_test_domain_model_company', 'MM' => 'tx_test_company_member_mm', 'size' => 10, 'autoSizeMax' => 30, 'maxitems' => 9999, 'multiple' => 0, 'wizards' => array( '_PADDING' => 1, '_VERTICAL' => 1, 'edit' => array( 'type' => 'popup', 'title' => 'Edit', 'script' => 'wizard_edit.php', 'icon' => 'edit2.gif', 'popup_onlyOpenIfSelected' => 1, 'JSopenParams' => 'height=350,width=580,status=0,menubar=0,scrollbars=1', ), 'add' => Array( 'type' => 'script', 'title' => 'Create new', 'icon' => 'add.gif', 'params' => array( 'table' => 'tx_test_domain_model_company', 'pid' => '###CURRENT_PID###', 'setValue' => 'prepend' ), 'script' => 'wizard_add.php', ), ), ), ), ``` Wäre super, wenn man das so lösen könnte! ### [#7](https://www.typo3.net/d/117172-kleine-frage-zu-at-cascade/7) · harald1972 · 2014-01-31 Hi, also erstmal: der Artikel sieht recht brauchbar aus. Ich werde das mit clone mal testen. Und das mit toArray() auch. Zum Thema "eigene m:n-Verknüpfung als Entität": Sinn der Sache ist, daß du diesem Vertrag (contract) z.B. eine Rolle (als ValueObject) zuweisen kannst, wie Teamleiter, Projektleiter, Entwickler, Hausmeister, usw... Und daß diese Mitarbeiter z.B. Arbeitszeiten verbuchen können... Herr Müller hat 3 Stunden für Firma soundso (am Projekt soundso) gearbeitet, oder sonstige Informatinen, die der Mensch in Verbindung mit der bestimmten Firma hat. Zu n:m-Beziehung aus zwei Seiten betrachten: Ich denke, daß du dafür beide MM-Tabellen brauchen wirst, je eine aus jeder Richtung. Was in einer Richtung mit uid_local verknüpft ist, ist bei der anderen uid_foreign. *Btw: Ich wüsste selbst gern mal, wofür sorting_foreign da ist.* Wenn's bei dir in die eine Richtung klappt, kopier's doch und vertausche alle company und member. Sollte für die andere Richtug dann genau so tun. Möglicherweise will das für Konflikte sorgen... Wenn du also eine Company löschst und damit auch alle MM-Beziehungen zu allen Members, möchtest du vielleicht auch die MM-Beziehungen von den entsprechenden Members zu dieser Company löschen. Eventuell musst du dafür dann noch selbst sorgen. Wenn du aber nur eine einzige MM-Tabelle für beide Richtungen willst, musst du einer Richtung mitteilen, dass uid_local, uid_foreign, sorting ummappen willst... möglicherweise mit TS ### [#8](https://www.typo3.net/d/117172-kleine-frage-zu-at-cascade/8) · Unbekannter Benutzer · 2014-02-04 So, wer sucht wird klug :-) Ich habe zu dem Thema "bidirektionale N:M-Beziehung" in Typo3-Erweiterungen folgende sehr hilfreiche Links gefunden, welche Licht ins Dunkel bringen: Gute Erklärung zu N:M-Beziehungen und deren Umsetzung allgemein: TCA-Dokumentation für den Type "select" mit Erklärungen zu den MM-Angaben: Um eine bidirektionale Verbindung auch von meinen Mitarbeitern zu den Firmen über EINE Zuordnungstabelle zu erreichen, muss in dem TCA also lediglich noch ein Wert für "MM_opposite_field" ergänzt werden: ```php ... 'MM' => 'tx_test_company_member_mm', 'MM_opposite_field' => 'company', ... ``` Ich übergebe hier also die Information, dass die UID der company als uid_local genutzt werden soll. Damit verhindere ich das falsche Speichern der UIDs wie oben beschrieben. So kann die N:M-Beziehung aus zwei Sichten sauber mit einer Zuordnungstabelle gelöst werden. Den Weg über zwei Zuordnungstabellen würde ich auf keinen Fall gehen, da das zwangsläufig irgendwann zu fehlerhaften Daten führt und auch von der Datenbankmodellierung her mehr als unsauber ist. **Um deine Frage zu sorting_foreign zu klären:** Die Zuordnungstabelle tx_test_company_member_mm besteht aus den Feldern uid_local = ID der company (erster Tabellen-Name im Namen der Zuordnungstabelle) uid_foreign = ID des member (zweiter Tabellen-Name im Namen der Zuordnungstabelle) sorting = Sortierung der Mitarbeiter aus Sicht der Firma (wenn man sich die Mitarbeiter der Firma anzeigen lässt) sorting_foreign = Sortierung der Firma aus Sicht des Mitarbeiters (wenn man sich die Firmen der Mitarbeiter anzeigen lässt) **Zu N:M-Verknüpfung als Entität:** Ich gebe dir völlig Recht, dass es bei Zuordnungstabellen, die weitere Werte enthalten, wie z.B. mit dem Vertrag zwischen Firma und Mitarbeiter eher Sinn macht, diese als eigenes Objekt zu erstellen. Bei einfachen Zuordnungstabellen, wo wirklich nur die IDs der beiden zugeordneten Datensätze enthalten sind (und evtl. noch die Sortierung) und keine weiteren Werte, macht es meiner Meinung nach nicht so viel Sinn, sondern nur mehr Arbeit. Es ist also wie immer: "Es kommt darauf an" ;) **Um nochmal auf das eigentliche Thema zurück zu kommen:** Die Änderung im TCA und der Einbau der Bidirektionalität brachte in Bezug auf @cascade leider keinen Erfolg. Es ist nach wie vor so, dass mit @cascade beim Löschen in einer N:M-Beziehung die Datensätze in der Zuordnungstabelle vorhanden bleiben und NICHT gelöscht werden. Wenn man beim Löschen das deleted-Flag = 0 setzt ist das ja noch nachvollziehbar. Dem ist aber auch so, wenn ich explizit in der ext_tables.php angebe, dass gelöschte Datensätze wirklich entfernt werden sollen. Man muss hier also zwangsweise selbst Hand anlegen und für die Bearbeitung der Datensätze im Backend (zumindest was das Löschen angeht) selbst ein Backend-Modul für die Erweiterung schreiben, damit die Datenbank sauber bleibt. Mal schauen, ob das Handling in zukünftigen extbase-Versionen noch geändert wird. ### [#9](https://www.typo3.net/d/117172-kleine-frage-zu-at-cascade/9) · harald1972 · 2014-02-05 Schön, also ich fasse mal zusammen: Den Weg über zwei Zuordnungstabellen würde ich auch nicht gehen wollen. MM_opposite_field kannte ich bisher nicht, ist aber genau das, was ich mit 'ummappen' gemeint habe. Wann eine Verknüpfung zur Entität wird, steht auch unter deinem ersten Link, im Abschnitt "N zu M Relation mit Attributen"... Ich stelle hier also Konsens fest ;) Zum Thema @cascade remove Die Beziehungen, die Objekte miteinander haben, werden auch bei 1:N nicht gelöscht. (Hab ich oben schon mal geschrieben) Hast du eine Firma 1:n verknüpft mit Mitarbeitern und löschst diese Firma - es gelte delete=>'deleted', sonst sieht du's nicht - werden mit @cascade remove zwar auch die Mitarbeiter deleted, aber weder die Zuordnung in die eine noch in die andere Richtung. Die gelöschte Firma hat ihre Mitarbeiter noch, die gelöschten Mitarbeiter haben noch ihre Firma. Macht ja auch Sinn: Willst du einen Datensatz wiederherstellen, müsstest du diese Beziehung sonst extra wiederherstellen, was schwierig wird, weil das genau die Information ist, die du brauchst, um festzustellen, welche Objekte in Beziehung stehen/standen. Zu sorting(_foreign) Deine Erklärung ist trivial, vermutlich steckt auch wirklich nicht mehr dahinter. Ich denk mal, sorting_foreign ist bei mir immer 0, weil ich ja nur aus einer Richtung schaue. Weiterhin braucht TYPO3 das wohl nur fürs BE. Dieses betrachte ich aber hier bei meinem MM-Problem gar nicht. Ach und dann noch zu meinem Test... beides funktioniert, die Variante mit clone() und die mit toArray() Gruß und frohes Coden! --- Quelle: „Kleine Frage zu @cascade“, typo3.net, https://www.typo3.net/d/117172-kleine-frage-zu-at-cascade Beiträge von Mitgliedern des Forums. Bitte mit Link auf die Diskussion zitieren.