A Spring Data JPA repository creates a proxy that implements persistence operations and query methods against mapped entity properties.
Spring Data JPA repositories: derive a query from mapped properties
The downloadable Spring source kit pins Java 21 and Spring Boot 4.0.8 with its managed dependencies. Run mvn test to check the named fixture.
Make the predicate readable
StockRepository declares findByAvailableGreaterThanOrderByIdAsc. The suffix describes a strict greater-than predicate and an ascending identifier order; it refers to the Java entity property, not an arbitrary database column alias. The fixture changes account two to thirty available units, then a threshold of fifty returns accounts one and three. A threshold of one hundred returns no rows.
The repository is created with JpaRepositoryFactory and a shared EntityManager so its boundary is visible in a small fixture. The shared manager resolves the transaction-bound persistence context; it is not one manually shared mutable EntityManager used by multiple request threads. A Boot application normally registers repositories through its configured scanning path.
Writes need a transaction policy
The stock change executes within TransactionTemplate and becomes a dirty-checking update when the transaction commits. Fetching an entity and changing it after its context has closed does not imply the same outcome. Entity lifecycle explains managed and detached state.
A convenient method name does not prove an acceptable query plan. The result list in this fixture is small; a production stock search needs a limit, an index analysis and an explicit access policy. If the predicate grows into a long business sentence, a reviewed explicit query can be easier to maintain than an increasingly complicated derived name.
Checked source
package in.aitrove.contracts;
import java.util.*;
import org.springframework.data.jpa.repository.JpaRepository;
public interface StockRepository extends JpaRepository<JpaContracts.StockAccount,Long> {
List<JpaContracts.StockAccount> findByAvailableGreaterThanOrderByIdAsc(int minimum);
interface StockSummary {Long getId();int getAvailable();}
List<StockSummary> findSummaryByAvailableGreaterThanOrderByIdAsc(int minimum);
List<StockSummary> findTop2ByIdGreaterThanOrderByIdAsc(long afterId);
}Test the boundary
RepositoryQueryTest.derivedPredicateUsesMappedPropertyAndOrder checks this contract in the source kit. Excerpts belong to the named classes; use the downloadable files for imports, configuration and assertions.
Costs and boundaries
The test uses three H2 rows and checks values and ordering. Materializing r full entities retains O(r) application objects plus persistence-context state while managed. Actual database search cost depends on indexes, selectivity and the generated SQL; no production database plan is asserted.
Common Mistakes
- Use mapped property names rather than guessing column names.
- Do not assume changes to a detached entity are automatically committed.
- Bound collection-returning queries before exposing them to arbitrary input.
Read next
Spring JPA entity lifecycle: managed changes and detached objects, Spring Data JPA projections: return selected fields without a full entity, Spring Data keyset pagination: continue after the last stable identifier, Java interfaces and replaceable behavior.
