nulos vs colecciones vacías en hibernación

Question

Decir que tengo la siguiente clase mapeada-Hibernate:

public class ClassA {  
    @OneToMany(fetch=EAGER) 
    private List<ClassB> bList; 
} 

Cuando leo un objeto de ClassA de una sesión de Hibernate, el campo bList se inicializa con un objeto PersistentList, como se esperaba .

me encuentro con un requisito en el que en situaciones en las que la lista está vacía, necesito Hibernate para inicializar el campo bList a null, en lugar de con un vacío PersistentList. En teoría, Hibernate tiene la información que necesita para hacer esto, ya que la búsqueda en la lista es ansiosa. El problema es que de acuerdo con section 6.1 of the Hibernate docs:

Debido a las modelo, propiedades de colección de valor relacional subyacente hacer no soporta semántica de valor nulo. Hibernate no distingue entre una referencia de colección nula y colección vacía.

Esto tiene mucho sentido, pero espero que alguien pueda inventar una estratagema astuta para superar esta limitación. Estoy pensando que quizás algún mecanismo de escucha/devolución de llamada me permita reemplazar listas vacías con referencias nulas.

Answer 1

¿Ha intentado verificar el método getbList()? Se podría hacer:

if(bList.isEmpty()) 
    return null; 
return bList; 

Hibernate siempre va a crear un objeto para sus referencias, pero se le permite controlar los datos en el interior de la getter y setters. Si la lista tiene 0 elementos, siempre puede devolver nulo.

Answer 2

tengo curiosidad por qué considera esto una "limitación' - tiene un nulo bList en realidad tienen un diferente significado a su solicitud de una vacía bList

Creo que en la mayoría de las áreas, una colección nula? y una colección vacía tiene el mismo significado semántico, lo que supongo es por qué los desarrolladores de Hibernate intentaron limitar Hibernate a solo usar uno. No tiene mucho sentido comprobar siempre if (bList == null || bList.isEmpty) si los dos siempre terminan significando lo mismo.

Answer 3

Para el manejo en su código, la forma obvia es en el captador, sin embargo eso no ayuda si quieres evaluarlo en HQL.

dos ideas:

• Un constructor que lo establece en NULL si vacío.
• A @PostLoad/@PostConstruct método que hace lo mismo.