Как получить общий метод поиска/поиска с данными весны?

Question

Все, что мне нужно, это предоставить все мои репозитории с помощью общего метода поиска/поиска. Что-то вроде этого:

public interface BaseRepository<T, ID extends Serializable> 
    extends PagingAndSortingRepository<T, ID> { 

    Iterable<T> search(SearchParameters sp); 

} 

где SearchParameters объект представляет собой набор значений для каждого свойства, и, вероятно, является условием для применения на них.

Критерии Jpa - это, вероятно, путь, но мне действительно трудно найти то, что соответствует моим потребностям.

Answer 1

Я использовал один подход, который идет в одном направлении, но я бы скорее сказал его динамический подход вместо общего. Теперь он работает очень хорошо, и мы можем автоматически создавать все нужные фильтры, просто предоставляя объект поиска. Я также думал, что критерии api - это путь, но через некоторое время он просто стал слишком беспорядочным со всеми побочными эффектами, и я обернулся, создав строку запроса с параметрами самостоятельно.

Создал объект entityscanner, который принимает все сущности домена и генерирует объекты фильтрации для каждого требуемого фильтра. Этот сканер принимает объект и следует свойствам до определенного уровня (чтобы сохранить количество фильтров в состоянии ожидания). Я не могу дать вам код здесь, так как это принадлежит клиенту, но подход, который я могу предоставить.

Что мне нужно в определении фильтра: thistype, propertypath, propertytype, valuesexpression, если мы визуализируем параметры (think masterdata), необходимые соединения (чтобы избежать объединения нескольких раз в одни и те же таблицы), открывать/закрывать скобки. Это определение фильтра.

Затем вам нужен объект значения, содержащий текущую конфигурацию пользователя: Inputvalue, operator (> =), скобки, ссылку фильтра (и/или).

С помощью этого мы можем сделать полностью динамический фильтр с небольшими ограничениями. Я не выполнял родительские запросы одного и того же объекта.

Вы можете начать простой генерировать дополнительный запрос для каждого фильтра. Например: где id in (select ....) и/или id in (select ...) Это работает нормально, если количество сущностей не слишком велико, но вы почувствуете снижение производительности нескольких подзапросов, если количество строк в таблице сущностей домена высокая. Затем вы погружаетесь и находите способ разделить соединения, необходимые для пути свойств, и в requestcreator вы будете пытаться объединить сущности только снова, если это необходимо.

Как сказано. Начните просто. Возьмите свойства первого уровня простых типов, таких как строка, и создайте свой механизм запросов. Увеличьте его, следуя конкретным объединениям объектов, и после того, как вы сходите с ума и вводите выражения, выбирающие параметры для выбора рендеринга или использования службы преобразования для входных параметров и т. Д.