Support projections on query methods that take a dynamic query type (Specification or Querydsl Predicate) [DATAJPA-1033]

[spring-projects-issues]

Sebastian Staudt opened DATAJPA-1033 and commented

Currently there seems no (at least no obvious) way to mix projections and specifications.

class ExampleRepository extends JpaRepository<Example, Integer>, JpaSpecificationExecutor<Example> {

    // Overriden from JpaRepository, just to show the whole picture
    // Works without problems
    @Override
    List<Example> findAll();

    // A bit odd, due to the "By", but works - see DATAJPA-680
    List<ExampleProjection> findAllProjectedBy();

    // Overriden from JpaRepository, just to show the whole picture
    // Works without problems
    @Override
    List<Example> findAll(Specification<Example> spec);

    // This would be great, but doesn't work.
    List<ExampleProjection> findAllProjectedBy(Specification<Example> spec);

}

A query method like the last above causes a java.util.NoSuchElementException inside org.springframework.data.jpa.repository.query.CriteriaQueryParameterBinder#bind during query. (Which may be another problem on its own.)

---

Affects: 2.0 M1 (Kay), 1.11 RC1 (Ingalls), 1.10.6 (Hopper SR6)

Issue Links:

• DATAJPA-393 Add support for QueryDSL projections in JPA repositories

Referenced from: pull request #430

107 votes, 96 watchers

[spring-projects-issues]

Oliver Drotbohm commented

There's currently a clean separation between query methods and dynamic queries using either Specification or Querydsl. The latter two only work to the extend of what APIs JpaSpecificationExecutor and QuerydslPredicateExecutor expose respectively. Projections on the other hand only work with query methods.

Your findAllProjectedBy() is — despite being an unusual one as it doesn't declare any criteria — a standard query method. I can see how this looks compelling if reduced to a the most simple — and by that at the same time most unrealistic — way of using that. What is supposed to happen, if the query methods contain criteria expressions themselves? What if a manually declared query is used with the query method?

I guess we could check the query method for that special case (like "It takes a well known dynamic query type like Specification and Querydsl's Predicate") and outright reject any criteria elements declared in the method or a manually declared query

[spring-projects-issues]

Sebastian Staudt commented

I think the most valuable benefit would be to reuse more complicated specifications (e.g. with multiple joins) and be able have a projected view at the same time.

As an example I switched various parts of an application to specification to restrict the view on objects based on user permissions or filters set in the application. This works great. The queries are efficient and the developer experience is fantastic. The code is much more readable and dynamic. Instead of defining dozens of query methods you can mix and match specifications on demand.

Currently, it feels like choosing between optimized results (projections) and powerful queries (specifications)

[spring-projects-issues]

Sebastian Staudt commented

Recently, I found a workaround for implementing this feature in a custom repository implementation (see Gist).

The main problem here is that QueryUtils.toExpressionRecursively is not package-private. This seems appropriate as it is an internal helper method.
But as long as this issue is not resolved I think it should be made public.

If a future step might incorporate code similar to mine into SimpleJpaRepository it would have to be public, too.

[spring-projects-issues]

daniel r. commented

hi,

any updates on this?

Best Regards,
DR

[spring-projects-issues]

Marc Collin commented

any update?

 

any complex dynamic search will pass by an custom repository implementation.... and no projection is possible

[spring-projects-issues]

sfwhite commented

I'm also in support of this.

We have a use case where we have complex search criteria built out in specifications, but we need a lightweight result object (projection). We currently have to map to the lightweight by hand, as there isn't a way to combine the two easily.

I also found a similar github project referenced from a stackoverflow question.

There's definitely demand for this enhancement

[spring-projects-issues]

Sergio Clares Martínez commented

??We have a use case where we have complex search criteria built out in specifications, but we need a lightweight result object (projection).??

Same here.

Regards

[spring-projects-issues]

Morjoh commented

Any news about this?

@Query(value = "",@Query(value = "", countQuery = "", nativeQuery = true)
Page<ProfileProjection> findByXXX(Specification<ProfileProjection> spec, Pageable pageable);

No exceptions, Specification is just being ignored without creating the "where" statement

[spring-projects-issues]

Christophe Maillard commented

Currently, it feels like choosing between optimized results (projections) and powerful queries (specifications).

Exactly. As I had to chose either/or, I've chosen specifications, but being able to project the results would be ()()(*)

Any news about this?

[spring-projects-issues]

Mahesh commented

Need above feature "Specifications with projections and pagination" very badly

[spring-projects-issues]

Hurelhuyag commented

Any news? Any workaround?

[spring-projects-issues]

Warsic Dia commented

I stumbled to this problem today.

And I think it's a "must have" to be able to mix projection and specifications.

in the meantime I found this github repository which could be a workaround.

But I did not give it a try yet

[spring-projects-issues]

Matija Folnović commented

Hello!

This issue, together with other related issues ( DATAJPA-393, DATAJPA-51, DATAJPA-1189 ) have a total of ~109 votes. Just thisissue alone is 3rd in total votes.

I'm aware you have limited resources and you need to somehow prioritize issues, but is there a way to prioritize this as it's cleary highly requested issue? :)

Another clear indicator this is highly requested is workaround Github repository above, which at the moment has 69 stars.

Thank you very much for all the hard work you do here! :)

[spring-projects-issues]

ziomill commented

This improvement would be great!

[spring-projects-issues]

Bernhard Kern commented

Yes, this improvedment would help us alot, is there any update in 2020. Thx!