redwhite90 ,
Да хз, почему он не обернул. А почему он должен был обернуть? В примере http://docs.jboss.org/hibernate/orm/3.2/api/org/hibernate/Query.html#setParameterList(java.lang.String, java.lang.Object[])]здесь они руками обернули в скобки.

Basil A. SidorovНу и не факт, что подзапрос в having - хорошая идея, даже если синтаксис/СУБД это допускают.Я бы поостерегся делать такие заявления. Что плохого в подзапросе в havaing? Ну подзапрос и подзапрос, having и having. Скорость выполнения запроса беспокоит? Да вроде нет. Ну значит ничего плохого в этом нет.
Вот будет беспокоить запрос - тогда да, надо смотреть на план, и искать проблему. В противном случае это будет "premature optimization", которая ни к чему хорошему не приводит.

redwhite90свеном,

поиск по странице ключевой фразы авторsetParameterList не дал результата примера использования и соответственно непонятно что он в примере обернул

Я бы не удивился, если бы он и там и там обернул, либо ни там ни там, а то он в одном месте оборачивает, в другом нет, как девушка прямо.Вот сслыка, скопируйте е от и до вместе с пробелом, там в описании метода пример http://docs.jboss.org/hibernate/orm/3.2/api/org/hibernate/Query.html#setParameterList(java.lang.String, java.lang.Object[])

redwhite90Вдогонку спрошу, есть ли смысл переписывать такой запрос на hql?Писать запросы на HQL имеет смысл, если:
1) Вам нужна переносимость приложения между базами данных. Т.е. сегодня SQL Server, завтра Oracle. В реальности это просто маркетинговый бред. Единственное, это может быть полезно для тестов.
2) У вас есть договоренность в команде писать по максимуму на HQL, например, потому что другие ваши коллеги не секут в SQL синтаксисе определенной СУБД.
Все. На этом причины использовать HQL заканчиваются.

ivanraМне кажется, запрос можно слегка оптимизировать:
- не нужен join с таблицей skill, достаточно чтобы candidate_skill.skill_id in (:skillIdList)
- не нужен вложенный запрос в конце, так как количество заранее известно и его можно передать вторым параметром (skills.size()). Конечно, при условии, что список skills валидный
Ну, а после этого попытаться сделать на hql. Переносимость системы - важное преимущество, что бы там ни говорили. Если это не legacy система, с которой уже ничего не поделаешь, лучше попытаться."Переносимость системы" это фикция, маркетинговая байка. Когда создают типичное трехзвенное приложение, то:
- либо база данных изветсна наперед, лицензии закуплены, менять ее никто не собирается. В этом случае переносимость нафиг никому не сдалась.
- с выбором БД еще не определились, или же она будет скорее всего бесплатной, или еще что-то, что говорит в пользу того, что переезжать возможно придется. В этом случае переносимость оправдана.

Более того, как только приложение преодолевает некую планку по сложности или требованиям к производительности, переносимость не то, что не помогает, она начинает тянуть приложение на дно, так как на HQL запросах вы не можете выжать из СУБД все соки.
Наконец, в реальной жизни практически никогда не бывает "гладких переездов", когда БАЦ - и ты пересел на новую СУБД без изменения кода. Не бывает такого. Взять хотя бы аннотации для ключей - на SQL Server это identity, а на Oracle - это сиквенсы. И все, приехали - надо лезть менять код. И среди всех таких изменений, переписать несколько дестяков кастомных запросов - это одна из самых простых задач, на которую уйдет от силы несколько дней. Это капля в море по сравнению с развертыванием новой СУБД, ее настройкой, администрированием, и профилированием перформанса, на которые могут уходить месяцы.
Так что пишите себе спокойно обычный SQL и не парьтесь, если у вас нет каких-то явных причин писать переносимый код. А абстрактное "а вдруг мы переедем на другую СУБД в будущем" оставьте предсказамусам.