Hallo,
ich habe mir mit dem Extension Builder eine extbase-Extension erstellt, und hätte Fragen zu den Unterschiedlichen Beziehungen, die ich zwischen den Entities festlegen kann.
Soweit ich das verstehe, sollte die 1:n Beziehung eigentlich die "Rückwärtsrichtung" einer n:1 Beziehung sein.
Ich kann also sagen:
Ein Auto hat mehrere Räder (Auto=1, Räder=n) oder aber
Mehrere Räder sind Bestandteil eines Autos (Räder=n, Auto=1).
Nun habe ich in Büchern gelesen, dass die n:1 Beziehung intern als n:m modelliert wird wobei m=1 fest gesetzt wird.
Für mich ergeben sich nun folgende Fragen:
1. Gibt es sonstige Unterschiede zwischen 1:n und n:1 oder sind diese sonst völlig identisch (außer, dass Sie die Beziehung von einer unterschiedlichen Richtung modellieren)
2. In den vom Extension-Builder generierten Formularen zu Erstellung von Datenobjekten ist mir aufgefallen, dass ich bei einer 1:n Beziehung eingeschränkt bin. Im oberen Beispiel, kann ich nicht zuerst Räder erstellen und dann beim erstellen eines Autos, diese Räder auswählen, sondern muss beim Erstellen eines Autos direkt Räder erstellen, die dann nur diesem Auto zugewiesen werden können (?Identifying Relationship?)
Hingegen kann ich, wenn ich die Beziehung umgekehrt, mit einer n:1 Beziehung modelliere zuerst Räder erstellen und dann beim Erstellen des Autos, die zuvor erstellen Räder auswählen (?Non-Identifying Relationship?).
3. Passiert mir ähnliches wie bei 2. nachher wenn ich Objekte im Frontend generieren will? Kann ich also bei 1:n nicht zuvor die n Elemente erstellen und dann erst das 1er Element?
Ich wäre dankbar, wenn mir jemand diese Unklarheiten erklären könnte.
Möchte hier doch einmal einhaken:
Das Phänomen unter Punkt 2 kann ich bestätigen jedoch nicht wirklich erklären.
Bei zwei Models "Autor" und "Buch" lege ich z.B. bei "Autor" eine Relation "veroeffentlichung" an und versehe diese Relation mit 1:n (was in diesem Beispiel ja Sinn macht).
Wird nun im Backend ein Datensatz vom Typ Autor angelegt, kann ich nicht auf die bereits vorhandenen "Buchobjekte" zugreifen sondern bekomme ein Textfeld zur freien Eingabe.
Erst wenn die obige Relation umgedreht wird auf "n:1", ist eine Auswahl der Buchobjekte möglich.
Macht doch eigentlichen keinen Sinn, oder?
Eddy
Ich verstehe diese Relationen leider auch nicht, bisher.
Ich muss ja z.T. die Relationen in beide Richtungen einrichten, oder?
Bsp.
Klassen: Entwickler, Mitgliedschaft, Projekte
Die Klasse (auch Tabelle in Extbase) Mitgliedschaft stellt eine Beziehung her welche Entwickler mit Projekten verknüpft.
Entwicker -> 1:n -> Mitgliedschaft
Mitgliedschaft -> n:1 -> Entwicker
und
Projekte -> 1:n -> Mitgliedschaft
Mitgliedschaft -> n:1 -> Projekte
Somit habe ich eine n:m Beziehung zwischen Entwicker und Projekt.
(Solche werden ja bisher in Extbase nicht in der Datenbank verknüpft, sondern die Verbindungen werden über PHP hergestellt ?!? )
ZUSÄTZLICH:
Es gab in einer älternen Version des "Extension Builders" folgende Relations:
"0 ..* (foreign key)"
"0 ..1"
etc.
Wie werden diese Relations auf die 1:n, n:1, 1:1 etc. gemappt?
Danke und viele Grüße,
Robert
Auch wenn der Thread schon alt ist, ich möchte ihn auch nochmals aufgreifen.
Ich habe momentan das genau gleiche Problem wie der Threadstarter unter Punkt 2.
Was ich möchte ist, wenn ich das Auto erstellt habe und anschliessend Räder erstellt habe und als Zugehörigkeit das Auto angebe diese im Auto dann auch ersichtlich sind, bzw. beim Auto abgefragt werden können, welche Räder zu ihm gehören.
Hat jemand eine Idee wie sich das lösen lässt?
Der Thread müsste vielleicht nach Extbase/Fluid verschoben werden.
Naja, beim Auto mit Rädern Beispiel würde ja jedes Rad nur zu einem Auto gehören, d.h. das ist dann eine ManyToOne Relation aus der Sicht des Autos. ManyToMany wäre z.B. fe_users und fe_groups. Rein von der Datenbank her würde man ManyToOne so Umsetzen, dass die Räder jeweils in einem Feld speichern zu welchem Auto sie gehören. Bei ManyToMany sollte man eigentlich immer eine MM Tabelle benutzen.
Über Backendformulare würde man das wahrscheinlich am einfachsten per IRRE bearbeitbar machen.
Richtig, jedes Rad kann nur zu einem Auto gehören. Deshalb ja auch 1:n und umgekehrt n:1.
Inzwischen habe ich es so gelöst ich weiss aber nicht, ob das sauber ist.
// TCA beim Auto
'raeder' => array(
'exclude' => 0,
'label' => 'LLL:EXT:auto/Resources/Private/Language/locallang_db.xml:tx_auto_domain_model_auto.auto',
'config' => array(
'type' => 'inline',
'foreign_table' => 'tx_auto_domain_model_raeder',
'foreign_field' => 'zugehoerigkeit',
'maxitems' => 9999,
'appearance' => array(
'collapseAll' => 0,
'levelLinksPosition' => 'top',
'showSynchronizationLink' => 1,
'showPossibleLocalizationRecords' => 1,
'showAllLocalizationLink' => 1
),
),
),
// TCA beim Rad
'zugehoerigkeit' => array(
'exclude' => 0,
'label' => 'LLL:EXT:auto/Resources/Private/Language/locallang_db.xml:tx_auto_domain_model_rad.zugehoerigkeit',
'config' => array(
'type' => 'select',
'foreign_table' => 'tx_auto_domain_model_auto',
'minitems' => 0,
'maxitems' => 1,
),
),
Das einzige was jetzt noch nicht so schön ist, dass es den Refcounter im Backend beim Rad erst aktualisiert, wenn ich im Auto einmal auf Speichern drücke.
Hat jemand eine bessere Idee wie man das lösen könnte? Wäre es möglicherweise besser die Beziehung nur vom Rad zum Auto zu machen und umgekehrt nicht?
Doch sollte so passen. Das mit dem Refcounter ist halt ärgerlich aber nicht zu ändern. Würde natürlich wegfallen wenn man nur die eine Richtung macht....
Du kannst natürlich auch wenn es im Backend nicht definiert ist trotzdem im Model einen getter machen für alle Räder des Autos, kannst du dir ja aus dem Räder Repository holen.
kitsunet schrieb
Du kannst natürlich auch wenn es im Backend nicht definiert ist trotzdem im Model einen getter machen für alle Räder des Autos, kannst du dir ja aus dem Räder Repository holen.
Hallo,
wie würde das gehen mit dem Getter für die Räder? Ein Hinweis wäre nett.