Spring Data JPA — Repositories, Derived Queries, @Query, Specifications
Fast recall
Quick revision
Core answer
Repository (typically JpaRepository) and creating proxy implementations backed by `SimpleJpaRepository`. You get CRUD, Pageable, and Sort for free. Custom methods come from three places: (1) derived queries (findByStatusAndCreatedAtAfter(...) parsed from method name); (2) `@Query("JPQL" or "native")` for explicit queries; (3) `SpecificationJpaSpecificationExecutor) for dynamic predicates. Use DTO/interface projections to avoid loading full entities, `@EntityGraph` to kill N+1, and `@Modifying` for bulk UPDATE/DELETE. Gotchas: derived queries explode beyond 3-4 parameters, Page runs an extra COUNT (use Slice for large datasets), and native queries skip JPQL features and lose pagination unless you supply countQuery.Real Spring Data JPA usage; custom queries; dynamic queries; projections
Derived query method-name explosion; fetching full entity when only columns needed; forgetting `@Modifying` on UPDATE/DELETE
Discuss `Specification`, Query By Example, interface vs class projections, `Page` vs `Slice` performance, and Hibernate 6 enhancements
Interview-ready guide
Interview answer
Spring Data JPA generates implementations of your repository interfaces at startup. You extend JpaRepository and get CRUD for free; custom methods come from three mechanisms.
The three mechanisms:
- Derived queries parsed from the method name (
findByStatusAndCreatedAtAfter) - `@Query` annotation with JPQL or native SQL
- `Specification
` withJpaSpecificationExecutorfor dynamic predicates
When to stop using derived queries:
- Method name > 3-4 parameters
- Optional filters
- Aggregations
- Complex OR logic
Page vs Slice:
Pagerunscount(*)for total pages — slow on huge tablesSliceskips the count — uses 'fetch one extra to know hasNext'- For very large tables: cursor-based pagination
Projections avoid loading full entities — interface (closed: only declared columns; open: full entity + SpEL) or class-based with SELECT new.
`@Modifying` required on UPDATE/DELETE @Query; clearAutomatically=true and flushAutomatically=true keep the persistence context consistent.
N+1: prevent with @EntityGraph, JOIN FETCH, or DTO projections.
Auditing: @EnableJpaAuditing, @EntityListeners(AuditingEntityListener.class) on a @MappedSuperclass with @CreatedDate, @LastModifiedDate, @CreatedBy, @LastModifiedBy.
Spring Data JPA — Repositories, Derived Queries, @Query, Specifications
Direct Answer
Spring Data JPA generates repository implementations at startup by scanning interfaces extending Repository<T, ID> (typically JpaRepository<T, ID>) and creating proxy implementations backed by SimpleJpaRepository. You get CRUD, Pageable, and Sort for free. Custom methods come from three places: (1) derived queries (findByStatusAndCreatedAtAfter(...) parsed from method name); (2) @Query("JPQL" or "native") for explicit queries; (3) Specification<T> (with JpaSpecificationExecutor) for dynamic predicates. Use DTO/interface projections to avoid loading full entities, @EntityGraph to kill N+1, and @Modifying for bulk UPDATE/DELETE. Gotchas: derived queries explode beyond 3-4 parameters, Page<T> runs an extra COUNT (use Slice<T> for large datasets), and native queries skip JPQL features and lose pagination unless you supply countQuery.
Common Mistakes & Pitfalls
Derived query method-name explosion; fetching full entity when only columns needed; forgetting @Modifying on UPDATE/DELETE
Check your understanding
Answer these without looking back at the article.
- When should you switch from derived queries to `@Query` or `Specification`?
- How do interface projections compare to constructor expressions in terms of generated SQL?
- What is the difference between `Page` and `Slice` performance-wise?
- How do you eliminate N+1 problems with `@EntityGraph`?
Related interview prep categories
2Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.