Porque
@Query precisa ser corrigido em tempo de compilação usando JPQL ou mesmo a consulta nativa tornará esse tipo de coisa difícil de implementar, especialmente de uma maneira segura de tipo. Então, eu percebo que você está atrás da solução JPQL, mas esta é uma ótima oportunidade para aprender e aproveitar a
Specification interface e CriteriaQuery da JPA. É exatamente para isso. Dê uma olhada no seguinte repositório:
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[]{}));
}
};
}
}
Pode parecer um pouco complexo, mas na verdade não é quando você se familiariza com ele. O uso é simples, como:
@Resource
private Table1Repository repo;
repo.findAll(Table1Repository.multiLikeColumn1(Arrays.asList("%X%","%Z%")))
