Чем меньше код, в чем разница между двумя следующими подходами к построению предложения 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);
Причина, по которой я спрашиваю, заключается в том, что я рефакторинг устаревшего кода, где существует первый, но я ожидал последнего. Если они оба совпадают, я оставлю только прежний код.
Hibernate Disjunction используется для
Group expressions together in a single disjunction
что означает, что если вам нужно сравнить значения X или Y OR Z условно, вы можете перебрать и применить селективную дизъюнкцию
Так идеально в вашем случае Restrictions.in и Restrictions.Disjunction делает то же самое, я предпочитаю первое в этом случае.
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+"%")));
При заданном коде эти два ведут себя по-разному, когда stringArray имеет нулевые элементы.
Использование дизъюнкции с нулевыми выражениями создает достоверный SQL-запрос с 1=1 или эквивалентным.
Restrictions.in приводит к оператору IN без значений, что часто (возможно, какой-то SQL-диалект может справиться с этим) синтаксически неверно.