Parce que @Query doit être corrigé au moment de la compilation en utilisant JPQL ou même une requête native rendra ce genre de choses difficiles à implémenter, en particulier de manière sûre.
Je réalise donc que vous recherchez la solution JPQL, mais c'est une formidable opportunité d'apprendre et de tirer parti de la Specification interface et CriteriaQuery de JPA. C'est exactement pour ça.
Jetez un œil au dépôt suivant :
public interface Table1Repository // to use specifications in queries
extends JpaRepository<Table1, Long>, JpaSpecificationExecutor<Table1> {
@SuppressWarnings("serial")
public static Specification<Table1> multiLikeColumn1(List<String> likePatterns) {
return new Specification<Table1>() {
@Override
public Predicate toPredicate(Root<Table1> root, CriteriaQuery<?> query,
CriteriaBuilder criteriaBuilder) {
Path<String> column1 = root.get("column1");
// create a Predicate for each "column1 like 'xy%az%' you need
List<Predicate> predicates = likePatterns.stream()
.map(likePattern -> criteriaBuilder.like(column1, likePattern))
.collect(Collectors.toList());
// then "concatenate" list of likes with "OR"
return criteriaBuilder.or(predicates.toArray(new Predicate[]{}));
}
};
}
}
Cela peut sembler un peu complexe, mais en réalité, ce n'est pas le cas lorsque vous vous y familiarisez. L'utilisation est simple, comme :
@Resource
private Table1Repository repo;
repo.findAll(Table1Repository.multiLikeColumn1(Arrays.asList("%X%","%Z%")))
