Ponieważ @Query musi zostać naprawione w czasie kompilacji za pomocą JPQL lub nawet natywnego zapytania sprawi, że tego rodzaju rzeczy będą trudne do zaimplementowania, szczególnie w sposób bezpieczny dla typu.
Więc zdaję sobie sprawę, że szukasz rozwiązania JPQL, ale jest to niesamowita okazja do nauki i skorzystania z Specification interfejs i JPA's CriteriaQuery. To jest dokładnie po to.
Spójrz na następujące repozytorium:
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[]{}));
}
};
}
}
Może to wyglądać na nieco skomplikowane, ale w rzeczywistości tak nie jest, gdy się z nim zapoznasz. Użycie jest proste, na przykład:
@Resource
private Table1Repository repo;
repo.findAll(Table1Repository.multiLikeColumn1(Arrays.asList("%X%","%Z%")))
