Ограничения гибернации в сравнении с дизъюнкцией - PullRequest
15 голосов
/ 05 мая 2011

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

Disjunction disj = Restrictions.disjunction();
for (String value : stringArray) {
     disj.add(Restrictions.eq("code", value));
}
where.add(disj);

VS.

Restrictions.in("code", stringArray);

Причина, по которой я спрашиваю, состоит в том, что я рефакторинг старого кода, где существует первый,Я ожидал последнего.Если они оба одинаковы, я оставлю старый код в покое.

Ответы [ 3 ]

15 голосов
/ 06 мая 2011

Hibernate Disjunction используется для

      Group expressions together in a single disjunction

, что означает, что если вам нужно сравнить со значениями X ИЛИ ИЛИ Z условно , вы можете выполнить итерациюи применить выборочное дизъюнкция

Так что в идеале в вашем случае Restrictions.in и Restrictions.Disjunction делает то же самое, я предпочитаю первое вэто дело.

9 голосов
/ 16 апреля 2014

Restrictions.Disjunction дает нам явный контроль, например, он позволяет подобный оператор, где, как в операторе нет.

Например:

criteria.add(Restrictions.disjunction()
                        .add(Restrictions.eq("bill.stateCd", null))
                        .add(Restrictions.eq("bill.stateCd", ""))
                        .add(Restrictions.ilike("bill.stateCd","%"+stateCd+"%")));

не может быть достигнуто с помощью

criteria.add(Restrictions.in("bill.stateCd", Arrays.asList(null,"", "%"+stateCd+"%")));
3 голосов
/ 05 июня 2014

С данным кодом эти два ведут себя очень по-разному, когда stringArray имеет нулевые элементы.

Использование дизъюнкции с нулевыми выражениями приводит к правильному запросу SQL с 1=1 или эквивалентным.

Restrictions.in приводит к оператору IN без значений, который часто (хотя, возможно, некоторый диалект SQL может обработать это) синтаксически некорректен.

...