Generic class parameter not being bound to query [DATACMNS-1002]

[spring-projects-issues]

Michael Bragg opened DATACMNS-1002 and commented

Im in the process of upgrading our app and I've run into an issue related to changes made here to Parameter. We are upgrading from Spring Data Commons from 1.11.4.RELEASE to 1.12.x / 1.13.x. We have a hierarchical entity structure. e.g. ReasonLabel extends AbstractResolutionLabel. We have a table with a Discriminator Column for the name of the concrete type. We have the following query which previously worked:

@Query("SELECT label FROM AbstractResolutionLabel label WHERE label.group.id = :groupId AND label.providerType = :providerType AND TYPE(label) = :clazz")
<T extends AbstractResolutionLabel> List<T> findByGroupIdAndProviderTypeAndType(@Param("groupId") String groupId,
  @Param("providerType") ProviderType providerType, @Param("clazz") Class<T> clazz);

We are now getting the following error:

Caused by: org.hibernate.QueryException: Named parameter [clazz] not set
	at org.hibernate.query.internal.QueryParameterBindingsImpl.verifyParametersBound(QueryParameterBindingsImpl.java:234)
	at org.hibernate.query.internal.AbstractProducedQuery.beforeQuery(AbstractProducedQuery.java:1309)
	at org.hibernate.query.internal.AbstractProducedQuery.list(AbstractProducedQuery.java:1408)
	at org.hibernate.query.Query.getResultList(Query.java:146)
	at org.springframework.data.jpa.repository.query.JpaQueryExecution$CollectionExecution.doExecute(JpaQueryExecution.java:121)
	at org.springframework.data.jpa.repository.query.JpaQueryExecution.execute(JpaQueryExecution.java:85)
	at org.springframework.data.jpa.repository.query.AbstractJpaQuery.doExecute(AbstractJpaQuery.java:116)
	at org.springframework.data.jpa.repository.query.AbstractJpaQuery.execute(AbstractJpaQuery.java:106)
	at org.springframework.data.repository.core.support.RepositoryFactorySupport$QueryExecutorMethodInterceptor.doInvoke(RepositoryFactorySupport.java:483)
	at org.springframework.data.repository.core.support.RepositoryFactorySupport$QueryExecutorMethodInterceptor.invoke(RepositoryFactorySupport.java:461)
	at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179)
	at org.springframework.data.projection.DefaultMethodInvokingMethodInterceptor.invoke(DefaultMethodInvokingMethodInterceptor.java:61)
	at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179)
	at org.springframework.transaction.interceptor.TransactionInterceptor$1.proceedWithInvocation(TransactionInterceptor.java:99)
	at org.springframework.transaction.interceptor.TransactionAspectSupport.invokeWithinTransaction(TransactionAspectSupport.java:282)
	at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:96)
	at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179)
	at org.springframework.dao.support.PersistenceExceptionTranslationInterceptor.invoke(PersistenceExceptionTranslationInterceptor.java:136)
	... 57 more

It appears that from this line the new isDynamicProjectionParameter(…) is returning true, so the class parameter is not being bound, because both the parameter type and return type (T) are both equal.

I appreciate this change has been here for some time now. This seems like a valid query that should be work. Many thanks

---

Affects: 1.13.1 (Ingalls SR1), 1.12.8 (Hopper SR8)

Reference URL: #150

Referenced from: pull request #199

[spring-projects-issues]

Michael Bragg commented

Hi @olivergierke Does this look like a valid bug to you? Many thanks

[spring-projects-issues]

Michael Bragg commented

Sugested minor change to make the dynamic projection parameter bindable. Thanks

[spring-projects-issues]

Oliver Drotbohm commented

Thanks for the report. Just a quick acknowledgement that I see this is a problem. I guess we didn't expect anyone to bind class values to parameters really. I don't think that using @Param to make this bindable is an option as the purpose of the annotation is a completely different one and mixing up the two concerns is gonna cause issues with people already using it and still expecting the usage of the parameter as projection.

I am still undecided on how to proceed here as all ways out imply some weird consequences for either side of the equation: people trying to use class as a projection input or people using it as plain parameter. Taking this back to the team to decide how to proceed

[spring-projects-issues]

Michael Bragg commented

Thanks for the reply Oliver. Yes I've now realised that my small suggestion wouldn't be suitable. It would be possible to work around the issue, by creating dedicated repositories for the entities that extends the base entity for example (Something like this), but I'm still thinking it would be nice to have support for querying by type. e.g. Some sort of dedicated query keyword the maps to the discriminator somehow? Also are you aware or any offical documentation on how to use Sprint Data with entity hierarchies and the use of discriminator columns?

[rafg92]

Hi, are there any updates about this issue?

[odrotbohm]

Interestingly enough, this came up today in #2770. Working on a fix. A bit involved as it requires a few internal changes. We even thought about the option I previously ruled out (use @Param to force the parameter into binding) as a mitigating option. Could be interesting to only introduce this in the 2.x branch for folks that cannot upgrade to 3.0 just yet.

@rafg92 – what version are you currently working with? Would you be fine with a fix for this only added in 3.1, currently scheduled for release in mid April 2023 and inclusion in Boot 3.1 (to be released mid May 2023).

[mp911de]

Fixed via #2770