Skip to content

Allow Supertypes Specifications in JpaSpecificationExecutor  #3300

@aykborstelmann

Description

@aykborstelmann

See the following commit: 4c45125
I added a test in your codebase which is exactly the same as I am going to describe.

Suppose we have an abstract @MappedSupperclass AbstractMappedType and a concrete entity ConcreteType1 extending AbstractMappedType.

Then we also have MappedTypeRepository which is a @NoRepositoryBean but does extend JpaSpecificationExecutor and must therefore look like this:

@NoRepositoryBean
public interface MappedTypeRepository<T extends AbstractMappedType> extends JpaRepository<T, Long>, JpaSpecificationExecutor<T> {
}

However when using this repository in its abstract form, we face some issues.

@Autowired
@Qualifier("concreteRepository1")
private MappedTypeRepository<?> mappedTypeRepository;

@Test
void testUseMappedTypeRepository() {
  concreteRepository1.save(new ConcreteType1("Test"));

  List<? extends AbstractMappedType> findings = mappedTypeRepository.findAll(
      where(mappedTypeAttribute1Equals("Test")));
  assertThat(findings).isNotEmpty();
}

private static Specification<AbstractMappedType> mappedTypeAttribute1Equals(String attribute1) {
  return (root, query, criteriaBuilder) -> criteriaBuilder.equal(root.get(AbstractMappedType_.ATTRIBUTE1), attribute1);
}

This does not work because Specification<AbstractMappedType> cannot be applied as first parameter for
List<T> findAll(Specification<T> spec); of JpaSpecificationExecutor<T>.

IMO, the method JpaSpecificationExecutor#findAll should be defined as follows, accepting also specifications of supertypes of T.

List<T> findAll(Specification<? super T> spec); 

In fact, I have already implemented change, and you can have a look at #3301

Metadata

Metadata

Assignees

Labels

status: declinedA suggestion or change that we don't feel we should currently apply

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions