Есть у нас ентити юзер и ентити которые соответсвуют разным отношениям между пользователями (друзья, враги, собутыльники и т.д.).
Собственно что мы хотим уметь делать.
1) Текущий пользователь ищет других
a) мы хотим чтобы в результаты не попали те которые в каком-то отношении с этим текущим пользователем
б) что бы в результаты попали только те которые в каком-то отношении с этим текущим пользователем
2) Текущий пользователь ищет других и хочет видеть информацию о пользователе и о состоянии его отношений с этим пользователем, если отношений нету он просто видит пользователя.
Какие отношения участвуют будет задаваться как параметры для поиска. Количество отношений может увеличиваться могут появляться новые и т.д. т.п. В класса пользователя нету мапинга на отношения в отношений есть.
Приблизительно как эти ентити выглядят (они конешно сложнее но для данной задачи ничего другого нам не надо)
| Код |
|
В чем проблема:
Я не могу искать с помощью критерии User-ов у них нету мапингов в тоже время куча остальных критериев поиска (цвет глаз/место жительства и т.д.) относятся только к User.
И спользовать HQL чет не очень хочется но судя по всему по другому никак...
Ну допустим мы решим юзать HQL... но ведь это превратится в какойто кошмар с генерацией этих строк... придется писать какоето подобие критерии что бы все было хоть более-менее сносным.
Ситуацию как всегда усложняет куча существующего кода
Уже есть целая иерархия класов поиска которые завязаны на критерии. Если раньше методы которые добавляли новые критерии поиска получали криетрию от предка и добавляли туда свои условия... то щас так просто все не выйдет. Надо будет может какой обект квери куда будут добавляться условия и ток уже при самом его вызове с низ будет формироваться HQL. Но у меня чувство что я буду изобретать велосипед! повторюсь ведь я сделаю в результате какоето подобие критерии
и меня это очень смущает. Создается в печатление что дольжно быть простое и елегантное решение.Конешщно еще как вариант мы можем все это свести к вызову запроса потом обработке реузльтата через существующие сервисы...
Но это тоже не впечатляет есть предчувствие что это мягко говоря будет не очень производительно.
От пример:
Мы дольжны выдать на страничку 20 юзеров (конечно может быть и меньше если они не соответствуют требованиям но интересней варинант когда их больше).
1) мы находим всех пользователей которых заблокировал текущий и добавляем условие что бы юзер не был в этом списке
2) потом ищем 20 юзеров
3) проходим по 20 пользователях и получаем все отношения которые хотел бы видеть текущий
Вариант по хуже
1) делаем запрос на 20 юзеров которые соответствуют критериям
2) с этих 20 для каждого выясняем не заблочен ли он и если заблочен удаляем с результата
3) добавляем найденых пользователей в список
4) если у нас нету 20 пользователей идем в 1 иначе возвращаем первые 20 (так можна и 1000 запросов выполнить)
5) проходимся по ним и получаем для них отношения.
1 вариант кажется лучше 2 но не похож на очень то елегантное решение, а если пользователь заблокирует 500 человек у нас будет список для "not (user.id in (userIdList))" с 500 польхователями и тд.
Хотелось бы получить что то такого рода:
1) делаем запрос на 20 пользователей в котором джоиним пользователя с таблицей заблоченых так что бы в результат не попали пользователи которых текущий заблочил ( ну или это просто можна добавить условием в запрос)
2) проходимся по ним и получаем для них отношения. (это мне тоже не нравится но чето я сомневаюсь что можна както по другому. Может как вариант искать отношения текущего с пользхователями которые попадают в список айдишек тогда будет 1 запрос на отношение вместо 1 запроса на пользователя)
Поидее это будет похоже на проблему вывода чего-то в зависимости от настроек пользователя, но только в случае коргда, количество настроек не фиксировано и может увеличиваться соответственно код не дольжен зависеть от того что за настройки будут использоваться.
Хотелось бы узнать как вы боретесь с подобными проблемами ( в часности если нету мапинга все одна дорога HQL?).
п.с. где писать по хибернейту не понятно решил в этот раздел
п.п.с. надеюсь излодил все понятно