JPA Hibernate one-to-many orphanRemoval

Bei einer 1-n-Beziehung gibt es wieder die Möglichkeit dies uni- oder bidirektional auszudrücken:
Unidirektional:
Auf der 1-Seite liegt eine Collection vor, die nach JPA mit der Annotation @OneToMany versehen wird.
Die Collection besteht aus Entitäten der n-Seite, zwischen denen die Beziehung ja auch ausgedrückt werden soll.
Diverse Parameter können gesetzt werden:
- mappedBy
Der Besitzer der Beziehung. Wird dies bei der 1-Seite aufgeführt, dann ist die n-Seite der Besitzer der Beziehung bzw. Verwalter. Hier wird also die Instanzvariable der n-Seite angegeben. Dadurch wird auf der n-Seite das Fremschlüsselfeld(default) geführt, damit dbseitig die Beziehung hergestellt werden kann.
- cascade
- fetch

Soll die Beziehung bidirektional sein, dann wird auch auf der n-Seite eine Annotation bei der entsprechenden Instanzvariable gesetzt:
@ManyToOne
Hier gibt es interessantere Annotationen/Parameter, die gesetzt werden können.
Doch zunächst der Standard. Wird kein Name via @JoinColumn definiert, so erhält die Fremdschlüsselspalten folgenden Namen: Name der Instanzvariable + _ + Name des PK-Feldes

- @JoinColumn mit den Parametern:

• referencedColumnName - Name des Fremdschlüsselfeldes
• nullable - Muss die Beziehung gesetzt sein?
• orphanRemoval - bei true wird beim Löschen der Entität auf der 1-Seite alle referenzierten Entitäten der n-Seite gelöscht. Dies macht bspw. bei einer Komposition Sinn. In einigen Fällen kann auch über die Alternative @Embeddable bzw. @Embedded nachgedacht werden. Zur Realisierung der Komposition, d.h. Einzelbestandteile der Komposition werden über die Komposition gemanaged und Einzelteile alleine dürfen designtechnisch nie vorkommen, sollte man dann bei mappedBy die 1-Seite als Besitzer eintragen. Somit wird beim Löschen der Entität auf der 1-Seite vom JPA-Provider bspw. Hibernate auch die n-Seite gelöscht.
• cascade - bspw. kann hier über cascade = CascadeType.PERSIST festgelegt, dass bei einem persist-Aufruf alle referenzierten Entitäten der n-Seite ebenfalls persistiert werden.
• fetch - bzgl. Performance / Ladeverhalten sollte hier genau überlegt werden