@Query, @Modifying và Projection: Tùy Biến Truy Vấn Dữ Liệu

TL;DR: Khi Derived Query không đủ đáp ứng, sử dụng @Query để viết JPQL hoặc Native SQL trực tiếp. Với thao tác UPDATE/DELETE hàng loạt (bulk DML), bắt buộc khai báo @Modifying kết hợp @Transactional; lưu ý dùng clearAutomatically = true để tránh dữ liệu trong persistence context bị lỗi thời (stale). Để tối ưu hiệu năng đọc, dùng DTO Constructor Expression thay vì Interface Projection để database chỉ SELECT đúng các cột cần thiết.

Khi nào nên sử dụng @Query thay vì Derived Query?

Derived Query tiện lợi cho 1–3 điều kiện đơn giản nhưng bộc lộ giới hạn rõ rệt trong các kịch bản sau:

public interface ProjectRepository extends JpaRepository<Project, Long> {
    // JPQL voi Named Parameter
    @Query("SELECT p FROM Project p WHERE p.status = :status AND p.createdAt > :since")
    List<Project> findRecent(@Param("status") ProjectStatus status, @Param("since") Instant since);

    // JPQL voi Aggregate va Group By
    @Query("SELECT p.status, COUNT(p) FROM Project p GROUP BY p.status")
    List<Object[]> countGroupByStatus();

    // Native SQL cho PostgreSQL Full-Text Search
    @Query(value = """
        SELECT * FROM projects
        WHERE search_vector @@ to_tsquery('english', :query)
        ORDER BY ts_rank(search_vector, to_tsquery(:query)) DESC
    """, nativeQuery = true)
    List<Project> fullTextSearch(@Param("query") String query);
}

Tại sao thao tác Bulk Update cần @Modifying và clearAutomatically?

Mặc định, @Query được Spring Data hiểu là câu lệnh truy vấn đọc (SELECT). Khi thực hiện các thao tác DML như UPDATE hoặc DELETE, bạn bắt buộc phải đánh dấu @Modifying và bọc trong @Transactional.

Hiểm họa dữ liệu từ Bulk Update bỏ qua Persistence Context

Câu lệnh @Modifying UPDATE được thực thi trực tiếp xuống cơ sở dữ liệu qua JDBC statement. Do đó, nó bỏ qua hoàn toàn persistence context (L1 Cache):

1. Bạn nạp Entity A vào bộ nhớ qua findById (trạng thái Managed, status = ACTIVE).
2. Thực hiện @Modifying UPDATE đổi toàn bộ status thành ARCHIVED trong DB.
3. Entity A trong bộ nhớ vẫn giữ nguyên status = ACTIVE (bị stale).
4. Bạn vô tình gọi a.setName("New Name"), kích hoạt Dirty Checking.
5. Khi commit transaction, Hibernate flush Entity A xuống database và vô tình ghi đè ngược lại trạng thái cũ status = ACTIVE!

Khắc phục triệt để bằng clearAutomatically = true

@Modifying(clearAutomatically = true)
@Transactional
@Query("UPDATE Project p SET p.status = :newStatus WHERE p.status = :oldStatus")
int bulkUpdateStatus(@Param("oldStatus") ProjectStatus oldStatus,
                     @Param("newStatus") ProjectStatus newStatus);

Tham số clearAutomatically = true chỉ thị cho Hibernate xóa trắng (clear) toàn bộ persistence context ngay sau khi câu lệnh bulk update chạy xong, ép buộc các lệnh truy vấn kế tiếp phải nạp lại dữ liệu mới nhất từ database.

Tối ưu hóa hiệu năng đọc bằng Projection như thế nào?

Khi hiển thị danh sách gồm 50 dự án, UI chỉ cần 3 thông tin (id, name, status). Nếu tải toàn bộ Entity chứa 20 cột (gồm văn bản dài và metadata), hệ thống lãng phí tài nguyên mạng, RAM và CPU mapping.

So sánh Interface Projection và DTO Constructor Expression

1. Interface Projection: Khai báo interface với các getter tương ứng. Tuy tiện lợi nhưng Hibernate vẫn SELECT toàn bộ các cột rồi mới dùng Proxy để lọc ở tầng ứng dụng Java. Không tối ưu được lưu lượng SQL.
2. DTO Constructor Expression (Khuyến cáo chuẩn mực): Sử dụng Java Record kết hợp cú pháp SELECT new com.pkg.Dto(...) trong JPQL:

// DTO Record bat bien
public record ProjectSummary(Long id, String name, ProjectStatus status) {}

// Repository Query
public interface ProjectRepository extends JpaRepository<Project, Long> {
    @Query("""
        SELECT new com.olhub.dto.ProjectSummary(p.id, p.name, p.status)
        FROM Project p
        WHERE p.status = :status
    """)
    List<ProjectSummary> findSummaryByStatus(@Param("status") ProjectStatus status);
}

Câu lệnh SQL thực tế sinh ra:

SELECT p.id, p.name, p.status FROM projects p WHERE p.status = ?

Database chỉ quét đúng 3 cột, loại bỏ 100% dữ liệu dư thừa ngay từ tầng lưu trữ.

Bảng so sánh các kỹ thuật truy vấn dữ liệu

Những cạm bẫy phổ biến cần tránh là gì?

1. Quên @Modifying khi viết UPDATE/DELETE: Ứng dụng sẽ ném lỗi runtime Not supported for DML operations.
2. Quên clearAutomatically trên Bulk Update: Dẫn tới hiện tượng stale entity ghi đè ngược dữ liệu đã cập nhật.
3. Nhầm lẫn giữa cú pháp JPQL và SQL: Viết SELECT * FROM table_name thay vì SELECT e FROM Entity e trong @Query không có nativeQuery = true.
4. Lạm dụng Native Query cho các truy vấn đơn giản: Làm mất tính độc lập cơ sở dữ liệu và mất cơ chế kiểm tra cú pháp lúc startup của Hibernate.

Tự kiểm tra kiến thức

Bài tiếp theo: Specification & Auditing: Truy Vấn Động và Nhật Ký Thực Thể