Week 15: Advanced Spring Data — Specifications, Projections & Query Optimization

1. Dynamic Queries with JPA Specifications

A derived query method like findByStatusAndCategory works when the set of filters is fixed. It stops working the moment a search endpoint needs to combine an arbitrary, optional subset of filters — a user might filter by status alone, by category alone, by both, or by neither. Writing a derived method for every combination doesn't scale (five optional filters is already 32 combinations); a Specification lets you build the query's WHERE clause programmatically, adding only the conditions that actually apply.

package com.codeverse.week15;

import org.springframework.data.jpa.domain.Specification;

class TaskSpecifications {

    static Specification<Task> hasStatus(String status) {
        return (root, query, cb) ->
            status == null ? null : cb.equal(root.get("status"), status);
    }

    static Specification<Task> hasCategory(String category) {
        return (root, query, cb) ->
            category == null ? null : cb.equal(root.get("category"), category);
    }

    static Specification<Task> createdAfter(Instant after) {
        return (root, query, cb) ->
            after == null ? null : cb.greaterThan(root.get("createdAt"), after);
    }
}

Returning null from a Specification is deliberate, not a bug — Spring Data JPA's Specification.where() and .and() silently skip any null predicate, so a filter that wasn't supplied simply doesn't appear in the final WHERE clause at all, instead of matching everything or nothing.

interface TaskRepository extends JpaRepository<Task, Long>,
                                  JpaSpecificationExecutor<Task> {}

// in the service layer
Specification<Task> spec = Specification
    .where(TaskSpecifications.hasStatus(filter.status()))
    .and(TaskSpecifications.hasCategory(filter.category()))
    .and(TaskSpecifications.createdAfter(filter.createdAfter()));

List<Task> results = taskRepository.findAll(spec);

Extending JpaSpecificationExecutor<Task> alongside JpaRepository is what unlocks findAll(Specification) — the repository doesn't need a single new method written for this to work; the same interface now accepts any combination of the Specifications above, composed at request time based on which filter fields the caller actually supplied.

2. DTO Projections & Entity Graphs

findAll() returning full Task entities is wasteful the moment a list endpoint only needs three of a table's fifteen columns — every unused column still gets selected, mapped, and (worse) can trigger lazy-loading of associations nobody asked for. A DTO projection asks the repository to select and construct exactly the shape you need, directly at the query level.

interface TaskSummary {
    Long getId();
    String getTitle();
    String getStatus();
}

interface TaskRepository extends JpaRepository<Task, Long> {
    List<TaskSummary> findByStatus(String status);   // selects only 3 columns
}

Spring Data generates a proxy implementing TaskSummary at runtime and, critically, restricts the generated SQL's SELECT clause to only the columns the interface's getters expose — this is a real query-level optimization, not just a Java-side filter applied after fetching everything.

The other half of this section is Week 4's N+1 problem, revisited properly. Lazy associations avoid loading data you don't need — until you iterate a list and access that association on every element, which fires one extra query per row. An entity graph tells JPA up front which associations to fetch eagerly, in the same query, for this specific repository call:

interface TaskRepository extends JpaRepository<Task, Long> {

    @EntityGraph(attributePaths = {"assignee", "tags"})
    List<Task> findByProjectId(Long projectId);
}

Without the entity graph, fetching 50 tasks and touching task.getAssignee() on each one fires 1 query for the tasks plus 50 more — one per row — for the lazily loaded assignee. With it, JPA generates a single query with the appropriate joins, because the entity graph declares the intent up front instead of discovering it lazily, one row at a time, during iteration.

3. Batch Operations & Native Queries

Calling save() in a loop for 10,000 rows issues 10,000 individual INSERT statements (or worse, one SELECT per row first, to check whether it's an insert or an update). Batch inserts group statements together and send them to the database in chunks:

spring.jpa.properties.hibernate.jdbc.batch_size=50
spring.jpa.properties.hibernate.order_inserts=true
spring.jpa.properties.hibernate.order_updates=true

Batching alone isn't enough for a genuinely large bulk update, though — updating 10,000 rows by loading each entity, mutating it, and letting Hibernate's dirty checking issue individual UPDATE statements is still slow at scale. A bulk modifying query issues a single UPDATE ... WHERE statement directly against the database, bypassing the persistence context entirely:

interface TaskRepository extends JpaRepository<Task, Long> {

    @Modifying
    @Query("UPDATE Task t SET t.status = 'ARCHIVED' WHERE t.updatedAt < :cutoff")
    int archiveStaleTasks(@Param("cutoff") Instant cutoff);
}

@Modifying is required to tell Spring Data this @Query changes data rather than reading it — without it, Spring Data assumes a SELECT and the call fails. The tradeoff worth understanding: this update bypasses Hibernate's first-level cache entirely, so any already-loaded Task entities in the current persistence context won't reflect the change unless you explicitly clear or refresh them.

Some queries — a recursive CTE, a database-specific full-text search, a query tuned around a particular index — genuinely can't be expressed in JPQL. A native query escapes to real SQL when that's the honest answer, rather than fighting JPQL to approximate it:

@Query(value = """
    SELECT * FROM task
    WHERE to_tsvector('english', title) @@ plainto_tsquery('english', :term)
    """, nativeQuery = true)
List<Task> searchByFullText(@Param("term") String term);

4. Hands-on Exercise

5. Knowledge Check

Three quick questions. Expand each to check your answer.