@Query declares a custom repository query, so the method name need not follow query-derivation conventions. Spring Data JPA supports JPQL and native SQL; Spring Data JDBC uses SQL; Spring Data MongoDB uses MongoDB query filters. section 4.7 section 15.2.4 section 17.3.4
Common capabilities include:
- Bind parameters positionally or by name in JPA; JDBC parameters are named and require @Param, while MongoDB uses placeholders such as ?0 and ?1. section 4.7 section 15.2.4 section 17.3.4
- Use native SQL in JPA with nativeQuery = true, but accept reduced database portability; JDBC custom queries are SQL and therefore vendor-specific. section 4.7 section 15.2.4
- Add sorting and projections in JPA, including aliases and selected attributes; MongoDB supports field inclusion and exclusion through fields. section 4.7 section 17.3.4
- Use SpEL's entityName variable in JPA queries to resolve the entity mapped by @Entity. section 4.7
Named parameters in a repository
A Spring Data JPA repository can define `@Query("select u from User u where u.level = :level and u.active = :active")` with `findByLevelAndActive(@Param("level") int level, @Param("active") boolean active)`. The same method shape in Spring Data JDBC uses SQL: `SELECT * FROM USERS WHERE LEVEL = :LEVEL AND ACTIVE = :ACTIVE`.
Custom count for a relationship table
A Spring Data JDBC repository can count links without deriving a property that is absent from the mapped class: `@Query("SELECT COUNT(*) FROM USERS_ADDRESSES WHERE USER_ID = :USER_ID") int countByUserId(@Param("USER_ID") Long userId);`
The flexibility has a validation tradeoff: malformed derived-query names fail while loading the application context, whereas incorrect @Query definitions fail when the method executes. section 4.7
