Hibernate Restrictions.in vs. Disyunction

Question

Aparte de menos código, ¿cuál es la diferencia entre los siguientes dos enfoques para crear una cláusula IN utilizando la API de criterios de Hibernate? ¿Hay problemas de rendimiento? ¿Hay alguna lógica en la recuperación que me falta? Ambos parecen realizar lo mismo en cuanto a las filas devueltas.

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

VS.

Restrictions.in("code", stringArray); 

La razón que pido es porque estoy refactorización código heredado en el que el primero existe, pero que estaba esperando este último. Si ambos son lo mismo, voy a dejar el código heredado solo.

Answer 1

Hibernate Disjunction se utiliza para

 Group expressions together in a single disjunction 

lo que significa que, si se tiene que comparar con los valores de X, Y o Z condicionalmente, puede iterar sobre y aplicar selective disjunction

Así que lo ideal en su caso Restrictions.in y Restrictions.Disjunction hace lo mismo, prefiero el primero en este caso.

Answer 2

Restricciones. La disyunción nos da un control explícito, por ejemplo, permite un operador similar, mientras que en el operador no.

Por ejemplo:

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

biselan consigue con en

criteria.add(Restrictions.in("bill.stateCd", Arrays.asList(null,"", "%"+stateCd+"%"))); 

Answer 3

Con el código dado los dos se comportan de manera muy diferente cuando stringArray tiene elementos cero.

El uso de Disyunción con expresiones cero produce una consulta SQL válida con 1=1 o equivalente.

Restrictions.in conduce al operador IN sin valores, que a menudo (aunque puede tratarse con algún dialecto SQL) es sintácticamente incorrecto.