mappedBy in hibernate what is the advantage

[vijay jacob]

Basically i understand , this is to declare owner of the relationship.Also it reduces the sql query fired . when you save the child. the parent is not updated.

what is the real advantage of making this or when should the devloper really do this.

Also (Parent Library child -visit) how does the hibernate retrieve all the visit mean to ask libraryObj.getVisit().

[Bill Gorder]

Any time you have a bidirectional relationship with an @ManyToOne one side and a @OneToMany on the other side you should do this. I think it sounds like you have an idea of the advantages. Maybe I am not understanding the question.

[vijay jacob]

You need not write @mappedBy to make it bidirectional, i hope.

1. I wanted to know what performance improvement can be made by this statement .what is the trade off we are doing when gaining this performance.

2. Also when me make the owner that side of the relationship , there is no foregin key column exist in the parent side. So how do the parent retrieve the list of children.

is it internally hibernate does a left join?

[Bill Gorder]

Yes whenever you have a one to many or many to many a join is performed.

From the docs...

Since many to one are (almost) always the owner side of a bidirectional relationship in the JPA spec, the one to many association is annotated by @OneToMany(mappedBy=...)

@Entity
public class Troop {
    @OneToMany(mappedBy="troop")
    public Set<Soldier> getSoldiers() {
    ...
}


@Entity
public class Soldier {
    @ManyToOne
    @JoinColumn(name="troop_fk")
    public Troop getTroop() {
    ...
}  

Troop has a bidirectional one to many relationship with Soldier through the troop property. You don't have to (must not) define any physical mapping in the mappedBy side.

To map a bidirectional one to many, with the one-to-many side as the owning side, you have to remove the mappedBy element and set the many to one @JoinColumn as insertable and updatable to false. This solution is not optimized and will produce some additional UPDATE statements.

@Entity
public class Troop {
    @OneToMany
    @JoinColumn(name="troop_fk") //we need to duplicate the physical information
    public Set<Soldier> getSoldiers() {
    ...
}

@Entity
public class Soldier {
    @ManyToOne
    @JoinColumn(name="troop_fk", insertable=false, updatable=false)
    public Troop getTroop() {
    ...
}

Of course sometimes you do not want the back reference in your java code. For this case you can use a join table instead. See here:
http://en.wikibooks.org/wiki/Java_Persistence/OneToMany#Example_of_a_OneToMany_using_a_JoinTable_database

and if you are using JPA2 you can do it without a join table but I would never do this unless you are dealing with legacy DB that you cannot change.
http://en.wikibooks.org/wiki/Java_Persistence/OneToMany#Undirectional_OneToMany.2C_No_Inverse_ManyToOne.2C_No_Join_Table_.28JPA_2.0_ONLY.29

[vijay jacob]

How do we choose the owner side oneToMAny or ManyToOne ?

[Bill Gorder]

The owning side is the entity whose table has the join column. If you are using mappedBy the OneToMany is always the inverse side and the ManyToOne is always the owning side this is the most typical usage. Now say you instead chose to use a join table instead (this is not done as often especially if its bi-directional). In this case the one to many will be the owning side it might look something like this

 @OneToMany
  @JoinTable
  (
      name="EMP_PHONE",
      joinColumns={ @JoinColumn(name="EMP_ID", referencedColumnName="EMP_ID") },
      inverseJoinColumns={ @JoinColumn(name="PHONE_ID", referencedColumnName="ID", unique=true) }
  )
  private List<Phone> phones;

The table EMP_PHONE is a join table and does not correlate directly to a Entity. In this case the @JoinColumns are defined on the OneToMany side (if you were doing this you usually would not have a @ManyToOne side unless you are conforming to an existing ddl which had the join table). This would be one case where the OneToMany is the owning side.

Hope that helps.