Description
Due to spring-projects/spring-data-jpa#3076 we've noticed a bug occurring in an old repository class of ours.
The setup is as follows:
@Entity
public class EntityA {
// some fields, getters and setters...
}
@Entity
public class EntityB {
// some fields, getters and setters...
}
@Repository
public interface RepositoryA extends JpaRepository<EntityA, Long> {
@Query("SELECT b FROM EntityB b where b.field = :field")
List<EntityB> getEntityBBySomeField(final @Param("field") String field)
}This is the result of some legacy code, and likely someone being too lazy to create a separate repository class for just one method.
The QueryMethod object for this repository method now returns the class EntityA instead of EntityB when calling its getDomainClass method. The logic used to determine the correct domain class seems to always prioritize the repository type over the method domain type.
this.domainClass = Lazy.of(() -> {
Class<?> repositoryDomainClass = metadata.getDomainType();
Class<?> methodDomainClass = metadata.getReturnedDomainClass(method);
return repositoryDomainClass == null || repositoryDomainClass.isAssignableFrom(methodDomainClass)
? methodDomainClass
: repositoryDomainClass;
});This then causes the ReturnedType object for the method to mark the return type as a projection since the return type doesn't match the domain type, which then triggers the query rewrite from the issue above.
All that then results in a runtime exception since the generated constructor query is incorrect as our EntityB class doesn't have a constructor and the query validation fails with an obscure syntax error.
For now I'll fix this by just moving the method in question to a new repository, but it still feels like this should work, and it has worked for a long time without any issues.