DATAJPA-1033 Support projections on methods that take a Specification

[lorenzodee]

Related JIRA issue.

The current state of this PR does not yet cover projections for QuerydslJpaPredicateExecutor. But it does support projections for methods that accept a Specification.

While this is still a work-in-progress, I'd appreciate feedback/help/suggestions from the community.

---

In a nutshell, the methods in JpaSpecificationExecutor were overloaded with one that accepts a projection type.

public interface JpaSpecificationExecutor<T> {

	Optional<T> findOne(@Nullable Specification<T> spec);

	<P> Optional<P> findOne(@Nullable Specification<T> spec, Class<P> projectionType);

	List<T> findAll(@Nullable Specification<T> spec);

	<P> List<P> findAll(@Nullable Specification<T> spec, Class<P> projectionType);

	Page<T> findAll(@Nullable Specification<T> spec, Pageable pageable);

	<P> Page<P> findAll(@Nullable Specification<T> spec, Pageable pageable, Class<P> projectionType);

	List<T> findAll(@Nullable Specification<T> spec, Sort sort);

	<P> List<P> findAll(@Nullable Specification<T> spec, Sort sort, Class<P> projectionType);

	long count(@Nullable Specification<T> spec);
}

---

• You have read the Spring Data contribution guidelines.
• There is a ticket in the bug tracker for the project in our JIRA.
• You use the code formatters provided here and have them applied to your changes. Don’t submit any formatting related changes.
• You submit test cases (unit or integration tests) that back your changes.
• You added yourself as author in the headers of the classes you touched. Amend the date range in the Apache license header if needed. For new types, add the license header (copy from another file and set the current year only).

[Xustyx]

Projections make sense everywhere, but makes more sense when you are paging and sorting and working with filters to draw tables.

This is a must to have feature.

[Mr-DeWitt]

I've tried it and works like a charm.

I've implemented a GraphQL => Spring.Specification (pageable) mapper, which can create dynamic DB queries from the given GraphQL request. My only problem was when I first want to obtain the ids for the given page - because of the Specification - not only the ids are returned. I've 4M+ rows to page, without this projection implementation the query took about 10 secs, but with the projection it took 0.2 sec.

This is a MUST HAVE feature for Spring! :)

[kasim-ba]

This would be so helpful, as the amount of data you want to show to the user is mostly much smaller, than the data that can be queried. Essentially you receive a ton of data that you don't really need. Decreasing the traffic would be quite helpful to speed up almost any application.

[michkish]

Hey guys, will it be merged in 2.6.0 ? I think it will be greate useful for apps.

[gregturn]

I'm wondering if we need this somewhat intrusive addition in light of #2274.

List<UserProjectionInterfaceBased> users = repository.findBy(userHasFirstnameLike("v"), q -> q.as(UserProjectionInterfaceBased.class).all());

[gregturn]

Upon further review, and in light of #2274, we are declining this feature request. Spring Data JPA's fluent API, along with it's Specification focus, supports projections right now.

I realize this original request was in light of Spring Data JPA's 2.2.x branch line. However, that version is no longer supported. The most recent is OSS-supported branch is 2.6.x.

But since #2274 was a new feature, it's only found in Spring Data JPA 3.0.x and won't be backported. The same would be said if we had decided to pick this up as well.

Please check out Spring Data JPA's 3.0.0-M4 release, which should have this feature. It can also be found if you pick up Spring Boot 3.0.0-M3 release (which pulls in Spring Data 2022.0.0-M4 and thus Spring Data JPA 3.0.0-M4).