Ограничения в спящем режиме. В отличие от дизъюнкции

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

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

VS.

Restrictions.in("code", stringArray);

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

Ответ 1

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

      Group expressions together in a single disjunction

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

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

Ответ 2

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

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

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

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