views:

51

answers:

1

I've mapped two entities using JPA (specifically Hibernate). Those entities have a one-to-many relationship (I've simplified for presentation):

@Entity
public class A {

    @ManyToOne
    public B getB() { return b; }
}

@Entity
public Class B {

    @OneToMany(mappedBy="b")
    public Set<A> getAs() { return as; }
}

Now, I'm trying to create a relationship between two instances of these entities by using the setter of the one-side/not-owner-side of the relationship (i.e the table being referenced to):

em.getTransaction().begin();

A a = new A();
B b = new B();
Set<A> as = new HashSet<A>();
as.add(a);
b.setAs(as);

em.persist(a);
em.persist(b);
em.getTransaction().commit();

But then, the relationship isn't persisted to the DB (the row created for entity A isn't referencing the row created for entity B). Why is it so? I'd excpect it to work.

Also, if I remove the "mappedBy" property from the @OneToMany annotation it will work. Again - why is it so? and what are the possible effects for removing the "mappedBy" property?

+3  A: 

In bidirectional associations the JPA spec is defined such that the implementation only looks at the owning side of the association when it wants to see the current "state" of the association to determine what needs to be persisted and each bidirectional association has both an owning and an inverse side. This can avoid ambiguities (i.e. what to persist if both sides of the association are not consistent?) as well as give opportunities for optimizations and simpler implementations in the JPA implementors. Note that this is generally not a problem, because bidirectional associations should be maintained properly by you, not by JPA. When you always maintain bidirectional associations properly in your application (updating both sides and keeping them consistent), there is no problem.

OneToMany with mappedBy is an inverse side, hence the JPA impl does not look at this side when determining the state of the association on flush/transaction commit. It only looks at A.getB() and this is null, so the association is null for JPA.

OneToMany without mappedBy, so that is becomes the owning side, is only supported since JPA 2.0 but I think Hibernate supports it since ages. Thats why your example works if you remove mappedBy from OneToMany. In that case the OneToMany becomes the owning side and hence the implementation "looks at" this side to determine what to persist. This does not change the fact that your in-memory association is still incomplete. You should set both sides.

UPDATE: I don't know exactly what Hibernate does when you leave off the mappedBy from either side but I think it may result in less optimal SQL. See also: http://simoes.org/docs/hibernate-2.1/155.html , particularly the section about "inverse="false"". "inverse" is the native Hibernate term for JPA "mappedBy". That is, inverse="true" in a Hibernate mapping is the same as using mappedBy="other" in a JPA mapping, both mark this side as the inverse side that is ignored when determining updates to the association.

Thanks for the detailed answer.Without the "mappedBy" he also persists the data if I change the "many" side (A), so i guess it looks at both (or maybe it's just Hibernate?).No doubt you should manage the relationship at your side (in the memory), but sometimes you would only want to hold the "one" side without caring if its "many" entites are set right in the memory (referencing him).
errr

related questions