Description
It makes sense to leverage AOT processing to pre-process repository definitions and to prepare repository query methods for improved query execution so that we don't need to use runtime query generation and query derivation.
During AOT processing, we have all necessary details to determine the actual query, extract value expressions and to generate code that runs the query.
We could generate something along the lines of:
public List<User> findByLastnameStartingWith(String lastname) {
String queryString = "SELECT u FROM org.springframework.data.jpa.domain.sample.User u WHERE u.lastname LIKE ?1 ESCAPE '\\'";
Query query = this.entityManager.createQuery(queryString);
query.setParameter(1, "%s%%".formatted(lastname));
return (List<User>) query.getResultList();
}for a repository:
interface UserRepository extends CrudRepository<User, Integer> {
List<User> findByLastnameStartingWith(String lastname);
}AOT processing binds assumptions made during build-time processing into code so that repositories are assigned statically to a Spring Data module (i.e., Spring Data repositories are generally implemented by the availability of a store module if no store-specific annotations or repository declarations are being used).
Customizing bean registration code fragments allows mounting the generated AOT fragment to the final repository.
A major benefit is that all query processing and validation happens during build time and we no longer need to parse and derive queries provided through an AOT repository.
In certain arrangements, AOT repository query methods can become overly complex (e.g. JPA stored procedures, dynamic projections) in which it doesn't make sense to generate such a method.
Related, since we have all query information at hand, we could generate a repository JSON metadata file containing query details for later usage.
For the time being, we focus on imperative repository query methods. Reactive ones will be discussed at a later stage.