Здравствуйте, MasterZiv, Вы писали:

>> Нет, не будет, так как за пределы метода, составляющего критерий,
>> отдается не результат запроса, а объект Criteria, к которому еще будут
>> присоединятся условия выборки. Именно поэтому мне нужен один запрос не
>> через юнион.

MZ>Ты занимаешься какой-то ерундой. Ну, отдавай не Criteria, а массив Criteria.
MZ>Или отдавай что-то другое. Какая разница-то ?

Ага, например, можно отдавать число 42

Но за наводку спасибо. В конечном счете посмотрев на получившийся запрос, понял, что так класть на производительсность нельзя. Так что сделал полуобертку над хибернейтовским Criteria API, при помощи которой конечный пользователь моего пакета не будет подозревать о массиве Criteria.

Здравствуйте, elmal, Вы писали:

E>>У меня тогда этих left join было штук 6, и каждый еще соединялся еще с несколькоми таблицами (ох хотелось тогда высказать все, что я думаю о структуре базы, еле сдержался ). С in заработало быстрее, причем раз в 100 — скорость замерял.
E>Хотя, справедливости ради, запрос у меня был несколько посложнее, там у меня была задача похожая на твою, но там связи были по простым аттрибутам, которые с таблицей B были связана еще через 5 таблиц . Они не были даже внешними ключами и на них даже индексов не висело, потому и такой результат. Потом индексы добавили, я попросил того, кто занимается оптимизацией предыдущий запрос проверить, вроде один черт left join медленнее чем вложенные селекты с in оказалось.

У меня наоборот, через джойны запрос выполнялся на порядок быстрее.

Здравствуйте, Donz, Вы писали:

Всем спасибо.
В конечном счете из-за жесткого проседания производительности сделал через два разных Criteria, но со своей оберткой на хибернейтовским API. Таким образом, и запросы довольно шустро выполянются, и изначальное желание скрыть обязательные условия от пользователя моих классов удовлетворено.

. wrote:

>> Эти ограничения накладывает Hibernate Criteria API.
> Если ограничения не позволяют что-то сделать, то используй
> HQL/createQuery, а если и HQL слабоват, то используй SQL/createSQLQuery
> и не мучайся. Hibernate предназначен не усложнять жизнь, а упрощать.
Просто этот Criteria — не всемогущ, полагаю, что ты упрёшься в рамки возможностей (или уже упёрся) и придётся всё переделывать.
Так что, по-моему, это не самая лучшая идея отдавать Criteria куда-то наружу. Сделай специальный bean-объект для описания данных запроса и по нему генери что удобнее/производительнее — criteria/hql/sql.

Здравствуйте, ., Вы писали:

.>Просто этот Criteria — не всемогущ, полагаю, что ты упрёшься в рамки возможностей (или уже упёрся) и придётся всё переделывать.
.>Так что, по-моему, это не самая лучшая идея отдавать Criteria куда-то наружу. Сделай специальный bean-объект для описания данных запроса и по нему генери что удобнее/производительнее — criteria/hql/sql.

Пока еще не уперся. У меня уже есть обертка. Пока она почти напрямую работает с Criteria. Как не будет хватать — расширю функционал.