ORM & Impedance Mismatch — tại sao ánh xạ object sang table không bao giờ hoàn hảo

TL;DR: ORM (Object-Relational Mapping) là pattern ánh xạ tự động giữa Java object và SQL table — thay thế 40+ dòng JDBC boilerplate bằng annotation và interface. Tuy nhiên hai mô hình không tương đồng hoàn toàn: Java có inheritance, object identity qua ==, association qua object reference, và navigation nhiều bước; SQL chỉ có foreign key, JOIN, và primary key. Năm khác biệt này — inheritance, identity, association, navigation, granularity — gọi chung là object-relational impedance mismatch, và chính chúng là nguồn gốc mọi pitfall JPA/Hibernate. Hiểu mismatch là hiểu tại sao @Inheritance, @ManyToOne, lazy loading, và equals/hashCode theo ID tồn tại.

Phần REST API (đầu course) xây TaskFlow với ConcurrentHashMap in-memory. Mỗi lần restart data bay, không query phức tạp được, không transaction. Phần JPA này đổi sang PostgreSQL + JPA. Bài đầu tiên đặt nền tảng: ORM là gì, tại sao cần 3 layer, và tại sao không "map hoàn hảo" được — trước khi bài 02 đi vào annotation @Entity, @Id, @Column.

1. Tại sao ORM tồn tại — boilerplate JDBC

Code thuần JDBC lưu và đọc một Project:

// 40+ dong cho 2 method. App 20 entity -> 800+ dong boilerplate
public Long save(Project project) {
    String sql = "INSERT INTO projects (name, status, created_at) VALUES (?, ?, ?) RETURNING id";
    try (Connection conn = dataSource.getConnection();
         PreparedStatement ps = conn.prepareStatement(sql)) {
        ps.setString(1, project.name());
        ps.setString(2, project.status().name());
        ps.setObject(3, project.createdAt());
        try (ResultSet rs = ps.executeQuery()) {
            if (rs.next()) return rs.getLong(1);
            throw new RuntimeException("INSERT failed");
        }
    } catch (SQLException e) {
        throw new RuntimeException(e);
    }
}

public Optional<Project> findById(Long id) {
    String sql = "SELECT id, name, status, created_at FROM projects WHERE id = ?";
    try (Connection conn = dataSource.getConnection();
         PreparedStatement ps = conn.prepareStatement(sql)) {
        ps.setLong(1, id);
        try (ResultSet rs = ps.executeQuery()) {
            if (rs.next()) {
                return Optional.of(new Project(
                    rs.getLong("id"),
                    rs.getString("name"),
                    ProjectStatus.valueOf(rs.getString("status")),
                    rs.getObject("created_at", Instant.class)
                ));
            }
            return Optional.empty();
        }
    } catch (SQLException e) {
        throw new RuntimeException(e);
    }
}

Pain rõ ràng:

ORM (Object-Relational Mapping) là pattern giải quyết: developer khai báo Java class + annotation, framework tự sinh SQL. Mục tiêu: developer viết code business, không viết JDBC plumbing.

2. Ba layer abstraction — JPA, Hibernate, Spring Data JPA

Java không có một ORM duy nhất mà có 3 layer build trên nhau:

flowchart TB
    App["Application code"]
    SDJ["Spring Data JPA<br/>Repository abstraction"]
    JPA["JPA Specification<br/>jakarta.persistence"]
    HB["Hibernate<br/>implementation"]
    JDBC["JDBC Driver"]
    DB[("PostgreSQL")]

    App -->|"interface ProjectRepository<br/>extends JpaRepository"| SDJ
    SDJ -->|"EntityManager API"| JPA
    JPA -->|"Hibernate implements spec"| HB
    HB -->|"PreparedStatement ResultSet"| JDBC
    JDBC --> DB

2.1 JPA (Jakarta Persistence API) — spec, không phải code chạy

JPA là Jakarta Persistence API (trước đây là Java Persistence API), chuẩn ra năm 2006. Nó define contract cho ORM Java — bộ annotation (@Entity, @Id, @Column, @OneToMany), API (EntityManager, EntityManagerFactory), query language (JPQL), và lifecycle entity. JPA không có code thực thi — chỉ là interface và spec. Cần implementation để chạy được.

Lý do có spec: tránh vendor lock-in. Code viết với EntityManager + @Entity chuẩn JPA có thể chạy trên Hibernate, EclipseLink, hoặc OpenJPA mà không cần sửa business code.

2.2 Hibernate — implementation chiếm hơn 90% thị phần

Hibernate là implementation JPA phổ biến nhất (hơn 90% Spring app). Nó đọc annotation JPA và thực thi:

• Sinh SQL từ @Entity class và JPQL query.
• Map ResultSet trả về thành entity object qua reflection.
• Quản persistence context — first-level cache + dirty tracking (khi entity thay đổi trong transaction, Hibernate tự sinh UPDATE khi commit).
• Lazy loading qua CGLIB proxy: khi truy cập field @ManyToOne chưa load, Hibernate sinh thêm SQL.

Hibernate có từ năm 2001, trước khi JPA ra đời. JPA 1.0 (2006) thực chất standardize các ý tưởng từ Hibernate. Các alternative như EclipseLink (Oracle) hay OpenJPA (Apache) tồn tại nhưng hiếm gặp trong production.

2.3 Spring Data JPA — bỏ boilerplate còn lại

Ngay cả với JPA + Hibernate, vẫn phải viết boilerplate:

// Thuan JPA + Hibernate -- van phai viet query tay
@PersistenceContext
private EntityManager em;

public List<Project> findByStatus(ProjectStatus status) {
    return em.createQuery(
        "SELECT p FROM Project p WHERE p.status = :status",
        Project.class
    ).setParameter("status", status).getResultList();
}

Spring Data JPA loại bỏ luôn class đó:

// Spring Data JPA -- chi viet interface, khong viet implementation
public interface ProjectRepository extends JpaRepository<Project, Long> {
    List<Project> findByStatus(ProjectStatus status);
}

Không có implementation nào. Spring Data tạo proxy class lúc runtime, parse tên method findByStatus thành JPQL SELECT p FROM Project p WHERE p.status = ?1, rồi đăng ký proxy đó như Spring bean. Cơ chế này — method name parsing sang JPQL — là chủ đề của bài 03 — Repository abstraction & derived query.

3. Object-relational impedance mismatch — tại sao ánh xạ không hoàn hảo

ORM giải quyết boilerplate nhưng không thể xóa bỏ sự khác biệt căn bản giữa hai mô hình. Impedance mismatch là thuật ngữ mô tả năm khác biệt cấu trúc giữa Java object world và SQL relational world — đây là nguồn gốc mọi bug subtle khi dùng JPA/Hibernate.

flowchart LR
    subgraph OW["Java Object World"]
        direction TB
        I["Inheritance (extends)"]
        ID["Identity (== / equals)"]
        AS["Association (object ref)"]
        NA["Navigation (obj.rel.field)"]
        GR["Granularity (nested object)"]
    end
    subgraph RW["SQL Relational World"]
        direction TB
        IN["Khong co inheritance"]
        PK["Primary key"]
        FK["Foreign key + JOIN"]
        MJ["Multi-step JOIN"]
        FC["Flat columns"]
    end
    I --->|"mismatch"| IN
    ID --->|"mismatch"| PK
    AS --->|"mismatch"| FK
    NA --->|"mismatch"| MJ
    GR --->|"mismatch"| FC

3.1 Inheritance — Java có, SQL không có

Java: class SalariedEmployee extends Employee. SQL: không có cú pháp kế thừa.

ORM phải chọn một trong ba chiến lược ánh xạ, mỗi cái có trade-off riêng:

@Entity
@Inheritance(strategy = InheritanceType.JOINED)
public abstract class Employee { ... }

@Entity
public class SalariedEmployee extends Employee {
    private BigDecimal monthlySalary;
}

Chọn sai chiến lược → query chậm hoặc schema khó maintain. Đây là lý do @Inheritance annotation phải khai báo rõ ràng — ORM không thể tự suy luận trade-off bạn muốn.

3.2 Identity — Java dùng ==, SQL dùng primary key

Trong Java, hai object có thể có cùng nội dung nhưng là hai instance khác nhau (== trả false). Trong SQL, hai row có cùng primary key là một row.

ORM phải quyết định: "hai entity object có phải là cùng một record DB không?" Câu trả lời dựa trên primary key — nhưng mặc định Java equals() dùng object reference, không phải ID.

Hậu quả khi không override equals/hashCode theo ID:

Project p1 = repo.findById(42L).orElseThrow();
Project p2 = repo.findById(42L).orElseThrow();
// Neu khong override equals: p1.equals(p2) == false du cung ID 42
// HashSet<Project> co the chua 2 entry cung ID

Convention: entity nên override equals/hashCode dựa trên business key hoặc ID. Hibernate persistence context giải quyết vấn đề này trong phạm vi một transaction (cùng EntityManager trả cùng instance), nhưng ngoài transaction là trách nhiệm của code bạn.

3.3 Association — object reference vs foreign key

Java: order.customer là object reference. SQL: orders.customer_id là foreign key số, cần JOIN để lấy data customer.

ORM map object reference sang foreign key khi lưu, và phải quyết định khi load: tải Customer ngay lúc load Order (eager), hay đợi khi code truy cập order.customer mới tải (lazy)?

@Entity
public class Order {
    @ManyToOne(fetch = FetchType.LAZY)  // default cho @ManyToOne
    @JoinColumn(name = "customer_id")
    private Customer customer;
}

Lazy là mặc định vì thường không cần Customer khi chỉ xử lý Order. Nhưng lazy tạo ra LazyInitializationException nếu truy cập ngoài transaction — đây là pitfall phổ biến nhất JPA.

3.4 Navigation — path expression vs multi-step JOIN

Java cho phép navigation nhiều bước: order.customer.address.city. SQL phải viết tường minh: JOIN customers ON orders.customer_id = customers.id JOIN addresses ON customers.address_id = addresses.id.

ORM dịch path expression thành JOIN. JPQL hỗ trợ:

SELECT o FROM Order o WHERE o.customer.address.city = :city

Hibernate sinh:

SELECT o.* FROM orders o
JOIN customers c ON o.customer_id = c.id
JOIN addresses a ON c.address_id = a.id
WHERE a.city = ?

Vấn đề: navigation trong vòng lặp dễ sinh N+1 query. Tải 100 order rồi truy cập order.customer trong loop → 1 query lấy order + 100 query lấy customer. Giải pháp là fetch join: SELECT o FROM Order o JOIN FETCH o.customer. Bài 04 — Relationships đào sâu N+1 và fetch strategies.

3.5 Granularity — nested object vs flat columns

Java thường có object lồng nhau đại diện cho một khái niệm: Address bên trong Customer, Money (amount + currency) bên trong Product. SQL lưu flat columns: customer_street, customer_city, customer_country.

JPA giải quyết bằng @Embedded:

@Embeddable
public class Address {
    private String street;
    private String city;
    private String country;
}

@Entity
public class Customer {
    @Embedded
    private Address address;  // map sang cot street, city, country trong bang customers
}

Address không có bảng riêng — các field của nó được map trực tiếp vào bảng customers. Thiết kế này giúp code Java có domain model phong phú trong khi schema DB vẫn bình thường.

4. Cơ chế bên dưới — tại sao ORM chọn proxy cho lazy loading

Hiểu tại sao Hibernate dùng CGLIB proxy cho lazy loading là hiểu tại sao LazyInitializationException xảy ra — và tại sao nó chỉ xảy ra ngoài transaction.

Khi load một Order với @ManyToOne(fetch = LAZY) trên field customer, Hibernate không để order.customer là null. Thay vào đó nó đặt vào một proxy object — một subclass giả của Customer do CGLIB sinh ra. Proxy này biết customer_id nhưng chưa tải data thật.

sequenceDiagram
    participant Code
    participant Proxy as Customer$$Proxy (CGLIB)
    participant Session as Hibernate Session
    participant DB as PostgreSQL

    Code->>Proxy: order.getCustomer().getName()
    Proxy->>Session: isSessionOpen()?
    alt Session open (inside transaction)
        Session->>DB: SELECT * FROM customers WHERE id = ?
        DB-->>Session: ResultSet
        Session-->>Proxy: initialize with real data
        Proxy-->>Code: return name
    else Session closed (outside transaction)
        Proxy-->>Code: throw LazyInitializationException
    end

Khi code gọi bất kỳ method nào trên proxy (getName(), getEmail()...), proxy kiểm tra Hibernate session còn mở không. Session còn mở thì proxy tải data thật từ DB (đây là lazy load). Session đã đóng (hết transaction) thì proxy không có cách nào lấy data — nó ném LazyInitializationException.

Đây là lý do transaction boundary quyết định lazy loading có hoạt động không. Fix chuẩn: thêm @Transactional trên service method để session còn mở suốt quá trình xử lý, hoặc dùng fetch join để tải eager chỉ những chỗ cần — xem thêm tại bài 04 — Relationships.

5. Pitfall cốt lõi từ impedance mismatch

// PITFALL 1 -- LazyInitializationException (mismatch association)
@Service
public class OrderService {

    // SAI -- khong @Transactional
    public String getCustomerName(Long orderId) {
        Order order = repo.findById(orderId).orElseThrow();
        // Transaction cua repo.findById() ket thuc o day
        return order.getCustomer().getName();  // LazyInitializationException!
    }
}

// DUNG -- @Transactional giu session song
@Transactional(readOnly = true)
public String getCustomerName(Long orderId) {
    Order order = repo.findById(orderId).orElseThrow();
    return order.getCustomer().getName();  // OK -- session van mo
}

// PITFALL 2 -- equals/hashCode khong theo ID (mismatch identity)
Set<Project> seen = new HashSet<>();
Project p1 = repo.findById(1L).orElseThrow();
Project p2 = repo.findById(1L).orElseThrow();  // trong tx khac
seen.add(p1);
seen.add(p2);
// Neu khong override equals: seen.size() == 2, du cung record DB
// Fix: override equals/hashCode dua tren ID

// PITFALL 3 -- N+1 (mismatch navigation)
List<Order> orders = repo.findAll();  // 1 query lay 100 Order
for (Order o : orders) {
    System.out.println(o.getCustomer().getName());  // 100 query lazy load
}
// Tong: 101 query. Fix: JOIN FETCH o.customer trong query goc

6. Liên hệ các bài khác

• Bài 02 — Entity mapping: annotation @Entity, @Id, @Column, @GeneratedValue — nơi mismatch được map cụ thể trong code. Biết impedance mismatch trước giúp hiểu tại sao từng annotation tồn tại.
• Bài 03 — Repository abstraction: Spring Data JPA parse method name sang JPQL. Bài này giải thích layer 3 trong sơ đồ 3-layer ở trên.
• Bài 04 — Relationships: @OneToMany, @ManyToOne, fetch strategies, N+1 — trực tiếp từ mismatch association và navigation (mục 3.3 và 3.4 bài này).
• Spring Data JPA autoconfig: HibernateJpaAutoConfiguration và JpaRepositoriesAutoConfiguration setup EntityManagerFactory + repository proxy — đây là nơi 3 layer ghép lại thành một stack chạy được.

7. Deep Dive

Tóm tắt

• ORM tồn tại vì JDBC boilerplate: 40+ dòng cho 2 method, 80% code không liên quan business logic.
• 3 layer: JPA (spec/contract) → Hibernate (implementation: SQL generation, persistence context, lazy proxy) → Spring Data JPA (abstraction: repository interface, derived query).
• 5 mismatch là nguồn gốc mọi pitfall JPA: inheritance (không tương đương SQL), identity (== vs primary key), association (object reference vs foreign key), navigation (path expression vs multi-step JOIN), granularity (nested object vs flat columns).
• Lazy loading dùng CGLIB proxy: proxy kiểm tra Hibernate session còn mở không trước khi query DB — hết transaction là LazyInitializationException.
• Fix chuẩn: @Transactional trên service method (giữ session), hoặc fetch join (tải eager đúng chỗ).

Tự kiểm tra

List<Order> orders = repo.findAll();  // Query 1: SELECT 100 orders
for (Order o : orders) {
  // Moi lan goi getCustomer() khi customer la @ManyToOne LAZY
  // proxy kich hoat 1 query rieng
  System.out.println(o.getCustomer().getName());
  // Query 2 den 101: SELECT * FROM customers WHERE id = ?
}
// Tong: 1 + 100 = 101 queries

Bài tiếp theo: EntityManager, JPQL & Spring Data setup