|
|
Регистрация Восстановить пароль |
Регистрация | Задать вопрос |
Заплачу за решение |
Новые сообщения |
Сообщения за день |
Расширенный поиск |
Правила |
Всё прочитано |
|
Опции темы | Поиск в этой теме |
20.01.2010, 12:45 | #1 |
Новичок
Джуниор
Регистрация: 20.01.2010
Сообщений: 1
|
Hibernate criteria и джоин
Стена текста
Опишу проблему. Есть у нас ентити юзер и ентити которые соответсвуют разным отношениям между пользователями (друзья, враги, собутыльники и т.д.). Собственно что мы хотим уметь делать. 1) Текущий пользователь ищет других a) мы хотим чтобы в результаты не попали те которые в каком-то отношении с этим текущим пользователем б) что бы в результаты попали только те которые в каком-то отношении с этим текущим пользователем 2) Текущий пользователь ищет других и хочет видеть информацию о пользователе и о состоянии его отношений с этим пользователем, если отношений нету он просто видит пользователя. Какие отношения участвуют будет задаваться как параметры для поиска. Количество отношений может увеличиваться могут появляться новые и т.д. т.п. В класса пользователя нету мапинга на отношения в отношений есть. Приблизительно как эти ентити выглядят (они конешно сложнее но для данной задачи ничего другого нам не надо) Код:
Я не могу искать с помощью критерии User-ов у них нету мапингов в тоже время куча остальных критериев поиска (цвет глаз/место жительства и т.д.) относятся только к User. И спользовать HQL чет не очень хочется но судя по всему по другому никак... ash1 Ну допустим мы решим юзать HQL... но ведь это превратится в какойто кошмар с генерацией этих строк... придется писать какоето подобие критерии что бы все было хоть более-менее сносным. Ситуацию как всегда усложняет куча существующего кода :crazy Уже есть целая иерархия класов поиска которые завязаны на критерии. Если раньше методы которые добавляли новые критерии поиска получали криетрию от предка и добавляли туда свои условия... то щас так просто все не выйдет. Надо будет может какой обект квери куда будут добавляться условия и ток уже при самом его вызове с низ будет формироваться HQL. Но у меня чувство что я буду изобретать велосипед! повторюсь ведь я сделаю в результате какоето подобие критерии ash1 и меня это очень смущает. Создается в печатление что дольжно быть простое и елегантное решение. Конешщно еще как вариант мы можем все это свести к вызову запроса потом обработке реузльтата через существующие сервисы... Но это тоже не впечатляет есть предчувствие что это мягко говоря будет не очень производительно. От пример: Мы дольжны выдать на страничку 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?). п.с. надеюсь изложил все понятно Последний раз редактировалось Stilet; 20.01.2010 в 13:09. |
Похожие темы | ||||
Тема | Автор | Раздел | Ответов | Последнее сообщение |
org.hibernate.exception.SQLGrammarE xception: could not insert... | BopoHDark | Java Базы данных (JDBC, JPA, Hibernate) | 4 | 13.12.2009 15:29 |