When using QueryDsl developers should be able to provide their own implementation of EntityPathResolver [DATAREST-694]

[spring-projects-issues]

Vladimir Tsanev opened DATAREST-694 and commented

Use case that we have, has following requirements:

• Enable QueryDsl for rest repositories. So applications consuming the /\{repository\}/something endpoints can specify filters with ?property=value.
• Currently only exporting JpaRepositories via rest.
• Not actually using QueryDsl in application code that depends on repositories (it will be used only by client side applications, consuming the rest endpoints).
• Do not want QueryDsl Query classes generated, some of the reasons:
  • Too much unused classes
  • Complicates the build
  • Not really concerned about performance of query dsl path creating (caching them is sufficient enough).

Spring Data defines a strategy interface for resolving QueryDsl entity paths - EntityPathResolver. We want to provide our own implementation to be used by spring data jpa/rest, based on PathBuilder instead of the generated query classes.

However currently it is a painful experience to meet to above requirements. Here are some of the problems we met and some suggestions for improvements.

1. EntityPathResolver provided by QuerydslBindingsFactory is not actually used when creating instances of QueryDslJpaRepository, but a hard-coded reference to SimpleEntityPathResolver.INSTANCE
   1. Currently this could be worked around by providing custom repositoryFactoryBeanClass
   2. it would be better if sharing the same resolver between JpaRepositoryFactory and QuerydslBindingsFactory was easier.
2. QueryPredicateBuilder (wrongly?) assumes that Path instances returned by the resolver are instances of generated querydsl classes (see reifyPath).
   1. To workaround this we provide our custom implementation of QueryPredicateBuilder, but
      1. QueryPredicateBuilder is a class that and cannot be easily extended. We also want to be able to wrap it to provide alternative chained implementations.
      2. To provide custom QueryPredicateBuilder, one should extend RepositoryRestMvcConfiguration and override repoRequestArgumentResolver().

QuerydslAwareRootResourceInformationHandlerMethodArgumentResolver is package private, and we need to copy paste it in order to instantiate it in our configuration!

Maybe having QuerydslPredicateBuilder as a bean like QuerydslBindingsFactory would be better, extending RepositoryRestMvcConfiguration is something that we want to avoid because it disables spring boot's auto configuration.

---

Affects: 2.4 GA (Gosling)

8 votes, 9 watchers

[spring-projects-issues]

Dennis Laumen commented

Has there been any progress on this? Or some kind of workaround? If I understand the above correctly I'm having the same issue as described in this StackOverflow question

[spring-projects-issues]

David Welch commented

Just to weigh in, I've had the same experience for similar requirements. Making the classes extensible and/or configurable would be desirable

[spring-projects-issues]

Petar Tahchiev commented

+1 for this. We also have the same problem - ended up copying the whole QuerydslAwareRootResourceInformationHandlerMethodArgumentResolver class in our project

[spring-projects-issues]

chris marx commented

Is this also the same reason that querying on related entities that are one-to-many is also failing? - https://stackoverflow.com/questions/35181167/spring-data-rests-querydsl-integration-for-quering-subproperties-of-collection

and this one?

http://stackoverflow.com/questions/35918824/spring-querydslpredicate-questions

[spring-projects-issues]

Eric Turley commented

I think it might solve this, too: https://stackoverflow.com/questions/45989336/querydsl-web-query-on-the-key-of-a-map-field

To work around that issue, I programatically destroy the repoRequestArgumentResolver bean and register my own copy-paste monstrosity of the QuerydslAwareRootResourceInformationHandlerMethodArgumentResolver