In Hibernate, when people ask “types of joins” in an interview, they usually mean the joins used in HQL/JPQL. Remember, the SQL database ultimately performs the join, but you control it through your object-oriented queries.
There are 5 important join concepts you should master:
1. INNER JOIN
Returns only records where both sides have a match.
SELECT e
FROM Employee e
JOIN e.department d
WHERE d.name = :departmentName
Conceptually:
Employee ───── Department
│ │
└── matching ───┘
Only employees having a matching department are returned.
Interview Point: When you write just JOIN in HQL/JPQL, it generally defaults to an INNER JOIN.
2. LEFT JOIN
Returns all records from the left side, even if there is no matching record on the right side.
SELECT d
FROM Department d
LEFT JOIN d.employees e
Conceptually:
Department
│
├── Employee (Match found)
├── Employee (Match found)
└── no Employee ← (Department still included in result)
This is extremely useful when you want to retrieve all departments, including newly created ones that have zero employees.
3. RIGHT JOIN
Returns all records from the right side, including those without a match on the left.
Conceptually:
Employee Department
│ │
└──── JOIN ────┘
│
unmatched department
↓
included
Note for interviews: HQL support and practical usefulness for Right Joins can depend heavily on the Hibernate version and query form. In application code, LEFT JOIN is much more commonly used. Know the concept, but don't treat it as a primary pattern.
4. FETCH JOIN ⭐⭐⭐⭐⭐
This is the most critical join to understand for Hibernate interviews.
A fetch join is different from a normal join because it tells Hibernate: Join the related entity AND eagerly load that association into memory as part of this single query.
SELECT d
FROM Department d
JOIN FETCH d.employees
Why is it so important? It is the primary weapon used to solve the N+1 query problem.
- Without FETCH: 1 query to get 100 Departments. Then, 100 additional queries to get the Employees for each department. (Total: 101 queries).
- With FETCH JOIN: 1 query retrieves both Departments and all their Employees at once. (Total: 1 query).
5. CROSS JOIN
Every row from one side is combined with every row from the other side (A Cartesian Product).
If you have 3 Employees and 4 Departments, the result is 3 × 4 = 12 combinations.
A1 → B1
A1 → B2
...
A2 → B1
JPQL/HQL can express a Cartesian product, though it is usually something you use very intentionally, as the result size can grow exponentially and crash your application.
Important: JOIN vs JOIN FETCH
This is a highly common interview question. Know the difference between these two HQL queries:
Normal JOIN
SELECT d
FROM Department d
JOIN d.employees e
WHERE e.salary > 50000
The normal join is used purely to filter or query based on the relationship. It does not automatically mean that the employees collection is initialized and populated for every returned Department object.
JOIN FETCH
SELECT d
FROM Department d
JOIN FETCH d.employees
The purpose is to fetch the association along with the root entity so it is ready to use in Java without triggering LazyInitializationExceptions or N+1 queries.
Mental Check:
JOIN → Use relationship in query filtering.
JOIN FETCH → Use relationship + fetch data into the entity graph.
Interactive Look: Visualizing Joins and Fetching
To truly understand how rows are combined and brought into Java memory, interact with this visual model of SQL Joins versus Hibernate Fetch Joins.
Hibernate Join Summary
| Join Type | Meaning | Interview Importance |
|---|---|---|
| INNER JOIN | Only matching records on both sides | ⭐⭐⭐⭐ |
| LEFT JOIN | Everything from left side + matches | ⭐⭐⭐⭐ |
| RIGHT JOIN | Everything from right side + matches | ⭐⭐ |
| JOIN FETCH | Join + eagerly fetch association into memory | ⭐⭐⭐⭐⭐ |
| CROSS JOIN | Cartesian product (All combinations) | ⭐⭐ |
Important Interview Questions (FAQs)
No, do not confuse them. @OneToMany, @ManyToOne, @OneToOne, and @ManyToMany are Entity Relationship Mappings that define your schema structure. JOIN, LEFT JOIN, and JOIN FETCH are Query Operations used at runtime to retrieve data.
Normally, if an association is Lazy, querying 100 parents results in 1 query. Accessing the children later results in 100 separate queries (N+1). JOIN FETCH instructs Hibernate to execute a single SQL join query and map all the returned parent and child data into the Persistence Context immediately, taking the query count from 101 down to 1.
Because JOIN FETCH is so important, your next step should be studying the ecosystem around it: JOIN vs JOIN FETCH → The N+1 Problem → LAZY vs EAGER loading → JPA EntityGraphs. These four concepts are deeply connected and frequently tested.
Comments (0)