Comments 3
Не надо так делать никогда.
должно соответствовать названию поля в таблице БД
Название таблицы, которую присоединяем
А потом кто-то пришлёт что-то не то, и всё навернётся. Всё, что приходит из вне, априори невалидно, пока не доказано обратное, а посему мапинги пришедших с клиента значений на реальные имена делаются явно на бэке. Причём, абсолютно нет никакой необходимости разделять имя атрибута и таблицу. Модель на клиенте != модели на бэке. В идеале, конечно, определить фильтруемую модель на уровне интерфейса с поддерживаемыми фильтрами для каждого конкретного атрибута.
join = root.join(criteria.getTable());
Не взлетит, как только нужно будет фильтровать по нескольким атрибутам одной вложенной сущности.
Вообще, по-моему, спринговые спеки в общем случае не предназначены для такого использования. Более правильный способ (менее проблемный с точки зрения вылезания каких-либо косяков) - создание класса, реализующего интерфейс спецификации, под конкретный набор параметров.
А то, что описано в статье будет работать исключительно в тестовых примерах на моделях с простыми полями.
Не могу понять одного, чем этот метод лучше простого наследования repository от QuerydslPredicateExecutor (вместо наследования JpaSpecificationExecutor)? Ведь в его методы можно передавать адекватные предикаты, которые хотя бы читаемы в отличие от этого хаоса Specification и выглядят как нормальный код (без кучи дженериков, магических названий, констант, приведений типов и пр., не говоря уже про сомнительные правила для клиента, по типу передачи названия полей таблиц в виде строк...? серьезно?). Это, видимо, для м̶̶а̶з̶о̶х̶и̶с̶т̶о̶в̶ фанатов Criteria API способ создания фильтров или тут есть еще какой-то смысл помимо незнания querydsl?
Spring Data Specification: наложение фронтенд-фильтров на репозитории spring data