Hibernate is a practical Hibernate topic that becomes clear when you connect the definition to a small working example.
Use this page to understand what happens, why it happens, how to verify it, and what mistake usually breaks the concept.
After reading, practice Hibernate with a normal case, a boundary case, and a broken case so the idea becomes usable instead of memorized.
Hibernate Inheritance Mapping SINGLE_TABLE JOINED should be studied as a practical Hibernate lesson, not as a label. Start by naming the input, the rule that changes the input, and the result a learner should be able to predict after reading the page.
In the hibernate > inheritance-mapping page, the notes should connect the definition with a working scenario, a mistake that beginners actually make, and the exact check that proves the fix. That makes the topic useful for coding, debugging, and interview revision.
Hibernate supports mapping Java class hierarchies to relational database tables. There are four strategies:
| Strategy | Table Structure | Pros | Cons |
|---|---|---|---|
| SINGLE_TABLE | One table for all classes | Best performance, simple queries | Many nullable columns, no NOT NULL constraints on subclass fields |
| TABLE_PER_CLASS | One table per concrete class | No joins needed for single type | Polymorphic queries use UNION (slow), duplicate columns |
| JOINED | One table per class (parent + subclass tables) | Normalized, no nulls | Joins required for every query |
| @MappedSuperclass | No table for superclass | Share fields without polymorphism | Cannot query the superclass type |
import jakarta.persistence.*;
// SINGLE_TABLE: all subclasses stored in one table
// A discriminator column identifies the type
@Entity
@Table(name = "payments")
@Inheritance(strategy = InheritanceType.SINGLE_TABLE)
@DiscriminatorColumn(name = "payment_type",
discriminatorType = DiscriminatorType.STRING)
public abstract class Payment {
@Id @GeneratedValue(strategy = GenerationType.IDENTITY)
private Long id;
private double amount;
private java.time.LocalDate paymentDate;
// getters/setters...
}
@Entity
@DiscriminatorValue("CREDIT_CARD")
public class CreditCardPayment extends Payment {
private String cardNumber;
private String cardHolder;
// Stored in 'payments' table with payment_type = 'CREDIT_CARD'
// cardNumber and cardHolder are nullable for other types
}
@Entity
@DiscriminatorValue("BANK_TRANSFER")
public class BankTransferPayment extends Payment {
private String bankAccount;
private String bankCode;
// Stored in 'payments' table with payment_type = 'BANK_TRANSFER'
}
// Polymorphic query - fetches all payment types
// SELECT * FROM payments (single table, no joins)
// List<Payment> all = em.createQuery("FROM Payment", Payment.class).getResultList();
// TABLE_PER_CLASS: each concrete class has its own complete table
// No discriminator column needed
@Entity
@Inheritance(strategy = InheritanceType.TABLE_PER_CLASS)
public abstract class Vehicle {
@Id @GeneratedValue(strategy = GenerationType.AUTO) // TABLE_PER_CLASS requires AUTO
private Long id;
private String manufacturer;
private int year;
}
@Entity
@Table(name = "cars")
public class Car extends Vehicle {
private int numDoors;
private String fuelType;
// table 'cars' has: id, manufacturer, year, num_doors, fuel_type
}
@Entity
@Table(name = "motorcycles")
public class Motorcycle extends Vehicle {
private String type; // sport, cruiser, touring
// table 'motorcycles' has: id, manufacturer, year, type
}
// Polymorphic query uses UNION ALL (can be slow):
// SELECT id, manufacturer, year, num_doors, null AS type FROM cars
// UNION ALL
// SELECT id, manufacturer, year, null AS num_doors, type FROM motorcycles
// JOINED: normalized - parent table + subclass tables joined by FK
// Best for data integrity; requires JOIN for every query
@Entity
@Table(name = "employees")
@Inheritance(strategy = InheritanceType.JOINED)
public abstract class Employee {
@Id @GeneratedValue(strategy = GenerationType.IDENTITY)
private Long id;
private String name;
private String email;
private double baseSalary;
}
@Entity
@Table(name = "full_time_employees")
@PrimaryKeyJoinColumn(name = "employee_id") // FK to employees.id
public class FullTimeEmployee extends Employee {
private double bonus;
private int vacationDays;
// Query: SELECT e.*, f.bonus, f.vacation_days
// FROM employees e JOIN full_time_employees f ON e.id = f.employee_id
}
@Entity
@Table(name = "part_time_employees")
@PrimaryKeyJoinColumn(name = "employee_id")
public class PartTimeEmployee extends Employee {
private double hourlyRate;
private int hoursPerWeek;
}
// @MappedSuperclass: NOT an entity - no table created for it
// Subclasses inherit fields but cannot be queried polymorphically
import jakarta.persistence.*;
import java.time.LocalDateTime;
@MappedSuperclass
public abstract class BaseEntity {
@Id @GeneratedValue(strategy = GenerationType.IDENTITY)
private Long id;
@Column(name = "created_at", updatable = false)
private LocalDateTime createdAt;
@Column(name = "updated_at")
private LocalDateTime updatedAt;
@PrePersist
protected void onCreate() {
createdAt = updatedAt = LocalDateTime.now();
}
@PreUpdate
protected void onUpdate() {
updatedAt = LocalDateTime.now();
}
// getters/setters...
}
// Each subclass gets its own table with the inherited fields
@Entity
@Table(name = "products")
public class Product extends BaseEntity {
private String name;
private double price;
// table 'products': id, created_at, updated_at, name, price
}
@Entity
@Table(name = "categories")
public class Category extends BaseEntity {
private String title;
// table 'categories': id, created_at, updated_at, title
}
// NOTE: Cannot query BaseEntity directly:
// em.createQuery("FROM BaseEntity") // ERROR - not an entity!
@Repository
@Transactional(readOnly = true)
public class PaymentRepository {
@PersistenceContext
private EntityManager em;
// Polymorphic query - returns all Payment subtypes
public List<Payment> getAllPayments() {
return em.createQuery("FROM Payment p ORDER BY p.paymentDate DESC",
Payment.class)
.getResultList();
}
// Query only a specific subtype
public List<CreditCardPayment> getCreditCardPayments() {
return em.createQuery(
"FROM CreditCardPayment p WHERE p.amount > :min",
CreditCardPayment.class)
.setParameter("min", 100.0)
.getResultList();
}
// Use TYPE() function to filter by subtype in polymorphic query
public List<Payment> getCreditCardAndBankPayments() {
return em.createQuery(
"FROM Payment p WHERE TYPE(p) IN (CreditCardPayment, BankTransferPayment)",
Payment.class)
.getResultList();
}
// instanceof check in Java after fetching
public void processPayments() {
List<Payment> payments = getAllPayments();
for (Payment p : payments) {
if (p instanceof CreditCardPayment cc) {
System.out.println("Card: " + cc.getCardNumber());
} else if (p instanceof BankTransferPayment bt) {
System.out.println("Bank: " + bt.getBankAccount());
}
}
}
}
Hibernate should be learned as a practical Hibernate skill, not only as a definition. Start by asking what problem the topic solves, what input or state it receives, what rule it applies, and what visible result proves it worked.
A strong explanation of Hibernate includes the normal case, a boundary case, and a failure case. When you practice, write down the before-state, the operation, the after-state, and the reason the result changed.
This lesson was expanded because the audit reported: limited checklist/practice/mistake/FAQ notes . The added notes below focus on clearer explanation, more examples, and concrete practice so the topic is easier to understand from the page itself.
Imagine you are adding Hibernate to a small learning project. The first step is to choose the smallest scenario that still shows the main idea. Avoid starting with a large production design; it hides the concept behind too many details.
Next, isolate the moving parts. Name the input, the rule, the output, and the possible error. This habit makes the topic easier to debug because you can see whether the problem is caused by bad data, wrong configuration, incorrect syntax, timing, permissions, or misunderstanding of the rule.
Finally, compare two versions: one correct version and one intentionally broken version. The broken version is valuable because it teaches you how the topic fails in real work, which is usually what interviews and debugging tasks test.
@Entity
@Table(name = "lesson_hibernate")
public class HibernateNote {
@Id
private Long id;
private String status;
public void markReviewed() {
this.status = "REVIEWED";
}
}
try (Session session = sessionFactory.openSession()) {
Transaction tx = session.beginTransaction();
HibernateNote note = session.find(HibernateNote.class, 1L);
note.markReviewed();
tx.commit();
}
// The important idea is to know when Hibernate tracks the object and when SQL is flushed.
Memorizing Hibernate as a definition only.
Pair the definition with a small working example and a failure example.
Copying syntax without checking the state before and after.
Write the input state, apply the rule, then inspect the output state.
Ignoring the error path for Hibernate.
Create one intentionally broken version and document the symptom and fix.
Memorizing Hibernate Inheritance Mapping SINGLE_TABLE JOINED without the situation where it is useful.
Connect Hibernate Inheritance Mapping SINGLE_TABLE JOINED to a concrete Hibernate task.
Understand the problem it solves, the input or state it works on, and the visible result that proves the concept is working.
Use one tiny correct example, one boundary example, and one broken example. Compare the output or state after each change.
They often memorize the term without tracing the behavior. Tracing makes the rule easier to remember and debug.
Remember the problem it solves in Hibernate, then attach the syntax or steps to that problem.
Explore 500+ free tutorials across 20+ languages and frameworks.