Archief - jHibernate one-to-many update

Beste 9livers

Ik in mijn database een 1-op-veel relatie die ik met hibernate map naar de java-klasse.

Een klas heeft meerdere studenten en een student hoort juist toe tot 1 klas.

Dus in Java resulteert dit tot een List van Student objecten. Maar in de database heeft de student een vreemde sleutel klasId.

Het mappen gaat goed en dat werkt al. Maar er zijn ook niet toegekende studenten met als klasId de value NULL. In mijn java programma kan ik dan studenten toewijzen aan een bepaalde Klas. Dit updaten in de database gaat goed. Ik doe gewoon een update(Klas) en in de database wordt de id juist gewijzigd.

Maar wanneer ik een student verwijder uit zijn klas en ik een update doe blijft in de database het klasId ongewijzigd. Dit zou terug naar NULL moeten gaan zodat deze student in geen klas zit. Hoe kan ik dit nu verwezenlijken met hibernate?

Alvast bedankt

Heeft dit niet te maken met de inverse property in je mapping?

In je eerste geval (update(klas)) vertrek je van het parent object
In je tweede geval wil je vanaf je child een relatie wijzigen

Ben nog maar pas met hibernate begonnen, dus helemaal niet zeker

Zijn er in Java ondertussen geen betere ORM's dan hibernate?

Moto zei:

Zijn er in Java ondertussen geen betere ORM's dan hibernate?

Klik om te vergroten...

:ironic: ga ens terug naar de .NOT threads aub.
Als ge niet snapt hoe Hibernate werkt moet ge er hier niet op komen afgeven.

@TS hoe zien uw klassen Student en Klas (en hun mappings) eruit?

Het is ondertussen al opgelost. Er was iets fout gegaan in het doorsturen van mijn objecten. Aangezien ik nog maar net begonnen ben met Hibernate dacht ik dat het daar aan lag.

Is het trouwens aangeraden om met xml te werken voor de mapping of met annotations? Ik vind annotations precies een beetje codevervuiling. Met xml hou ik alles mooi gescheiden. Iemand die hier wat op te zeggen heeft?

Annotations zijn geen codevervuiling
Nee, persoonlijk ben ik voorstander van annotations.
Waarom?
Zo zie je in één oogopslag de mapping van uw object al je erin aan't werken bent. En het is net de bedoeling vind ik dat die dingen mooi samen zitten.
Dankzij "convention over configuration" kun je in sommige gevallen annoations weg laten en weet je dat het framework standaard bepaalde zaken op een bepaalde manier gaat configureren (nogal vaag beschreven, ik weet het). Maar ik heb een beetje een haat-liefde verhouding met die "convention over configuration" ...

Een tekortkoming aan annotations is dat je niet op een eenvoudige manier aan hun parameters kunt. Bijv wanneer je een constraint op de lengte van een kolom hebt gelegd, dan zou het handig zijn dat je die constraint uit de annotation kon halen om zo je object te valideren.

Daarnaast oogt het voor een relatief simpel projectje als dat van jou mooi gescheiden. Maar bij complexere projecten met bijv 50 entity-objecten is dat al minder plezant.
Als je dan nog eens bijv. Spring gaat gebruiken, wat ook configuratie in xml is (meerdere files afhankelijk van welke modules je gebruikt) als je geen annotations wil gebruiken...

Zo is de term "metadata-hell" ontstaan Daarom dat men blij is dat annotations uitgevonden zijn.

Een ander nadeel van annotations tov xml is dat je opnieuw mag compileren als je iets aanpast.
Daarom zou ik persoonlijk goed nadenken om named queries in annotations te duwen. Aangezien die wel regelmatig durven te veranderen (bijv bij performance aanpassingen)

Emerxill zei:

Een tekortkoming aan annotations is dat je niet op een eenvoudige manier aan hun parameters kunt. Bijv wanneer je een constraint op de lengte van een kolom hebt gelegd, dan zou het handig zijn dat je die constraint uit de annotation kon halen om zo je object te valideren.

Klik om te vergroten...

Dit bestaat toch al weg? Ik meen mij te herinneren dat Hibernate validator kan kan.

annotations zijn zeker beter dan de xml-files

Dankzij "convention over configuration" kun je in sommige gevallen annoations weg laten

Klik om te vergroten...

Teveel Conventions + Nieuwe developer = ?????
Ipv de convention, een annotation zetten voegt geen extra complexiteit toe aan uw code maar maakt uw code direkt leesbaarder voor nieuwe developers die niet elke conventie kennen.

Een tekortkoming aan annotations is dat je niet op een eenvoudige manier aan hun parameters kunt. Bijv wanneer je een constraint op de lengte van een kolom hebt gelegd

Klik om te vergroten...

Ben nu ook niet direkt een voorstander van constraints in annotations, probleem is dat men dan
- Validatie op meerdere plaatsen heeft (bv length in annotation rest in een class)
- De validatie dan enkel in de annotation wilt hebben (hopen custom framework code, geen ROI)
- Foutmeldingen in de annotation erbij steken -> probleem met vertalingen
- Objecten kunnen meerdere statussen hebben met aparte validatie

Een ander nadeel van annotations tov xml is dat je opnieuw mag compileren als je iets aanpast

Klik om te vergroten...

Het is eigenlijk andersom, ge moet tijd investeren in deftig ALM om makkelijk een nieuwe versie te deployen, dit mag zeker geen argument zijn om voor XML te kiezen

Een goede presentatie om eens te kijken als programmeur en zeker als ge Hibernate gaat doen is deze -> Simple-Made-Easy van de maker van Clojure
en ja Hibernate is niet "Simple" maar "Easy"

Just me zei:

Dit bestaat toch al weg? Ik meen mij te herinneren dat Hibernate validator kan kan.

Klik om te vergroten...

Hibernate validator is gewoon de implementatie van JSR 303.