Spring Data JPA Repository Methods — Derived, JPQL, Native
Fast recall
Quick revision
Core answer
findByStatusAndCreatedAtAfter parsed into JPQL at startup — are validated early and need zero code, but become unreadable past ~3 parameters. `@Query(JPQL)` is explicit JPQL with `@Param`, validated at startup, supports joins/aggregations/projections, and keeps method names clean. `@Query(value=..., nativeQuery=true)` drops to database-specific SQL for window functions, CTEs, full-text, JSON operators — at the cost of runtime-only validation, no portability, and no L2 cache. `@Modifying` is required for UPDATE/DELETE (clearAutomatically=true flushes the persistence context after, flushAutomatically=true flushes before). Pagination works everywhere via a trailing Pageable; native queries additionally need countQuery="...".Whether the candidate understands the three query definition approaches and their trade-offs
Creating long derived method names like `findByStatusAndCityAndCreatedAtAfterAndPriceLessThan` instead of using `@Query` for complex queries
Explain the query derivation mechanism, mention `@Param` for named parameters, projections for list views, and when derived queries become unmaintainable
Interview-ready guide
Interview answer
Spring Data JPA offers three ways to define query methods, and the right choice depends on complexity.
Derived method names:
- Spring parses the name at startup and generates JPQL
findByStatusAndCreatedAtAfter(String, Instant)->WHERE status = ? AND created_at > ?- Validated at startup — non-existent fields fail context load
- Stop when names exceed 3-4 parts
`@Query` JPQL:
- Explicit, readable, supports aggregations, joins, projections
- Use
@Paramfor named parameters; avoid positional - Validated against entity metadata at startup
`@Query(nativeQuery=true)`:
- For database-specific features — JSONB, window functions, CTEs, full-text
- Fails only at runtime; bypasses L2 cache; locks you to one database
- Always provide
countQueryforPage
Modifying queries:
@Modifyingrequired for UPDATE/DELETEclearAutomatically=trueprevents stale entity reads after the bulk update- Always run inside a
@Transactionalboundary
Production tips:
- Use interface projections for list views — no entity construction, no lazy proxies
Sliceinstead ofPagefor infinite scroll — skips the COUNT query- Native queries need an integration test per query — runtime validation only
Spring Data JPA Repository Methods — Derived, JPQL, Native
Direct Answer
Spring Data JPA offers three ways to define query methods. Derived queries — names like findByStatusAndCreatedAtAfter parsed into JPQL at startup — are validated early and need zero code, but become unreadable past ~3 parameters. @Query(JPQL) is explicit JPQL with @Param, validated at startup, supports joins/aggregations/projections, and keeps method names clean. @Query(value=..., nativeQuery=true) drops to database-specific SQL for window functions, CTEs, full-text, JSON operators — at the cost of runtime-only validation, no portability, and no L2 cache. @Modifying is required for UPDATE/DELETE (clearAutomatically=true flushes the persistence context after, flushAutomatically=true flushes before). Pagination works everywhere via a trailing Pageable; native queries additionally need countQuery="...".
Common Mistakes & Pitfalls
Creating long derived method names like findByStatusAndCityAndCreatedAtAfterAndPriceLessThan instead of using @Query for complex queries
Check your understanding
Answer these without looking back at the article.
- What's the performance difference between `Page<T>` and `Slice<T>` on a large table?
- How do interface projections compare to DTO projections for list endpoints?
- Why does `@Modifying` require `clearAutomatically` and `flushAutomatically`?
- When would you prefer native SQL over JPQL despite the portability cost?
Related interview prep categories
2Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.