Federdaten JDBC und Child Entity Gleichheit ⇐ Java

[Anonymous]

Ich studiere Spring Data JDBC über das Video von Maciej Walkowiak (), das eine Filmaggregation mit einer Eins-zu-Many-Beziehung zu Verleiheinheiten darstellt. Der Mieteinheit fehlt ein @ID -Feld, und es wird kein Gleicher/HashCode implementiert. Die Miettabelle verfügt über eine automatische Inkrementierungs-ID (nicht der Entität zugeordnet) und einen impliziten Movie_id Fremdschlüssel.
Hier ist die vereinfachte Struktur aus dem Video: < /p>

Code: Select all

]@Table("movie")
class Movie {
@Id
Long id;
String title;
Set rentals;
}

@Table("rental")
class Rental {
Duration duration; // No @Id, no equals/hashCode
Integer price;
}

Mein Anliegen:
Das Fehlen von Equals/HashCode in Mietproblemen, da die Entitäten in DDD eine identitätsbasierte Gleichheit haben sollten, nicht wertbasierte (z. B. Dauer und Preis). Für den Film kann Equals/HashCode ID verwenden, aber Miete hat kein Identitätsfeld. Das Basis von gleicher Dauer und den Preis scheint gegen DDD zu verstoßen, was darauf hindeutet, dass die Identität für Gleichheit auf Entitäten verwendet wird. Die automatische Inkrementierungs-ID der Miettabelle erscheint aufgrund der Lösch- und Einführung von Update-Strategie von Federdaten, die die ID-Werte ändert. Oder gilt meine Sorge überhaupt? Wenn wir die Gleichheit auf Objektreferenz basieren und nur Miete über den Film (z. B. addrentale (Mietverleih)) fügen, sollte die Dinge in Ordnung sein. Aber IRL, wir brauchen wahrscheinlich irgendwie, um mit einer bestimmten Miete zu interagieren (zum Beispiel endrental), und dafür brauchen wir sie zu unterscheiden. /> Fragen: < /strong> < /p>
Ist das Video -Bit simpel? Ich meine in der realen Welt, wir brauchen wahrscheinlich eine Möglichkeit, die Mieten voneinander zu unterscheiden. beabsichtigt, und stimmt mit DDD überein?>