What does Bidirectional navigation mean in Hibernate?

[Arun Singh Raaj]

Unidirectional mapping : "navigation from only one side"
Bidirectional mapping:   "navigation from both the sides"

May I know what does it mean when you say navigation from both the sides?
If Department has one to many relationship with Employee.  Does it mean I can fetch the record from Department table if i know Employee_id?


Thanks in advance.

[Tim Holloway]

If you have a relationship between 2 entities, for example, Department and Employee, you can have a one-way relationship (Employee->Department) or a two-way relationship (Employee<->Department).

In Hibernate, you define relationships using field annotations (@OneToOne, @OneToMany, @ManyToOne, @ManyToMany). A one-way (unidirectional) relationship would be one where the child table (Employee) has an object relationship with its parent (Department). A two-way (bidirectional) relationship has this relationship, but also a relationship (as a collection unless it's one-to-one) from parent to child(ren).

Because Hibernate is an object relational system, the application-level linkage isn't a field or field value as such, but instead an object. That means that you can read a set of records in a single operation, obtaining, for example, a selected department object containing a collection of all the department's employee objects. If the objects are defined with bi-directional relationships, you can then easily find data from one object via its linkage to the other using ordinary Java data references. For example, "thisEmployee.department.departmentName", or its getter/setter equivalent: "thisEmployee.getDepartment().getDepartmentName()".

Assuming a one-to-many relationship, the reverse direction references would look something like "thisDepartment.getEmployees().get(3).getName()" to get the name of the 4th employee in the department employee list. Note that List item numbers start with zero (which is why "3" for the fourth element) and the order of employees in the list would have to be also explicitly defined or the list would be in random order.

[Arun Singh Raaj]

Tim Holloway,  thank you for the response.
So how will this bidirectional mapping technique allow bidirectional traverse in context of SQL query?

[Tim Holloway]

Arun Singh Raaj wrote:Tim Holloway,  thank you for the response.
So how will this bidirectional mapping technique allow bidirectional traverse in context of SQL query?

It doesn't. Hibernate is designed to avoid making SQL queries. In normal operation, Hibernate will internally generate and execute whatever SQL operations it needs for the interaction with the database. The exact SQL that will be used is determined by Hibernate - but note that systems like Hibernate actually do database operations more efficiently than raw JDBC SQL can when running large-scale operations. Hibernate does have an SQL-like query language (JPQL), but since Hibernate is object-oriented, you don't normally use it for things like table joins, since Hibernate does them automatically.

From the application's point of view, you would obtain a department and its employees from a single Hibernate request, since the department entity object contains the employee entities as a collection. You can actually detach these objects from Hibernate completely and use them as a regular POJO collection, and that's exactly what I usually do in webapps. Depending on whether you have defined the operation as "lazy fetch" or "eager fetch", Hibernate may pre-load all the records into memory at the time you do your original query to find the department.

Going in the other direction, you can fetch an employee and Hibernate would automatically fetch the department (here again, you can do a "lazy fetch" or an "eager fetch"). You can, in fact, fetch an employee, use it to reference the department, then use the department to reference all of the other employees in the department. So, for example, it's an easy thing in Hibernate to look up Sally and see if Jerry is in the same department as Sally.

[Arun Singh Raaj]

Thank you so much for clearing the doubt, Tim.