Y si es así, ¿bajo qué circunstancias?

Javadoc y JPA especificaciones no dice nada.

  • Yo estaba buscando exactamente esta pregunta! tks! hasta 4!
InformationsquelleAutor rdk | 2009-07-12

7 Comentarios

  1. 67

    Que están a la derecha. La especificación JPA no dice nada acerca de ella. Pero de Persistencia Java con Hibernate libro, 2ª edición, dice:

    Si el resultado de la consulta está vacía, se devuelve null

    Hibernate implementación de JPA (Gerente de la Entidad) devuelve null cuando se llame a consulta.getResultList() sin ningún resultado.

    ACTUALIZACIÓN

    Como se ha señalado por algunos usuarios, parece que una nueva versión de Hibernación devuelve una lista vacía en su lugar.

    Una lista vacía se devuelve en Eclipselink así cuando no se encontró ningún resultado.

    • Este es sin duda anticuado, Hibernate devuelve una lista vacía.
    • Desde qué versión?
    • Todavía se me pone null desde el estado de Hibernación 4.3.10 (que se ejecuta como motor de JPA para la Primavera de Datos). Esto sólo ocurre para una sola consulta nativa, como es típico consultas de JPA funcionan como se esperaba.
    • Sólo echa tanto de las condiciones de uso de O. if(rows == null || rows.size == 0){} donde las filas es lo que el getResultList() devuelve
    • Basta con ponerla en un Opcional.ofNullable() y listo.
    • Creo que volver null en lugar de una lista vacía no es lo que se pretende por parte de la especificación, ya que de lo contrario, deja bastante claro cuando se espera null en otros lugares. Especialmente como la documentación de getResultList lee Execute a SELECT query and return the query results as a(n) (un)typed List. - @return a list of the results. Me gustaría comprobar null de curso y devuelva una lista vacía de mí mismo si es necesario.

  2. 21

    Si las especificaciones dice que podría no suceder, tendría que creer en ellos? Dado que el código podría ejecutar en contra de mayo de diferentes JPA implementaciones, se confía cada implementador para obtener el derecho?

    No importa qué, yo sería el código a la defensiva y comprobar el valor null.

    Ahora la gran pregunta: debemos tratar el «null» y una Lista vacía como sinónimos? Aquí es donde las especificaciones deberían ayudarnos, y no.

    Mi conjetura es que una devolución null (si es que realmente podría ocurrir) sería el equivalente a «yo no lo entiendo la consulta» y la lista vacía sería «sí, se entiende la consulta, pero no hubo registros».

    Vez usted tiene una ruta de acceso del código (probablemente una excepción) que se ocupa de unparsable consultas, tendería a dirigir un null volver por ese camino.

    • +1 usted tiene razón cuando dice: «se confía cada JPA proveedor?» NO 🙂
    • Editado para añadir: Arthur ha señalado que Hibernate JPA, de hecho, devuelve null si no hay registros se encuentran. Así que, de hecho, en este caso, es necesario que no se pliegan nulo y vacío de la lista. Yo creo que el proceso de pensamiento que nos pasó por encima, todavía es válida. Es incluso concebible que deberíamos tienen tratamientos distintos de null para diferentes JPA pilas. Bienvenido a la portabilidad de la diversión.
    • De acuerdo. No sólo existe «la portabilidad de la diversión», debido a que la especificación JPA no hace lo que debe hacer … especificar la semántica precisa. La vergüenza es dirigido por el comité con intereses creados.
    • «Yo no lo entiendo consulta» deben ser manejados como Exception, volviendo null donde Collection es en el tipo de retorno es un evidente error de diseño
  3. 13

    Contrario a Arthur post, cuando yo estuve a cargo de una consulta que no hay entidades coincidentes tengo una lista vacía, no es null. Este es usando Hibernate y es lo que me parece correcto comportamiento: una lista vacía es la respuesta correcta cuando usted pide una colección de entidades, y que no hay ninguna.

    • para OpenJPA, también tengo una lista vacía en lugar de null.
  4. 3

    Si usted toma una mirada cercana a la org.hibernate.loader.Loader (4.1) verás que la lista siempre se inicializa en el interior de la processResultSet() método (doc, fuente).

    protected List processResultSet(...) throws SQLException {
       final List results = new ArrayList();
    
       handleEmptyCollections( queryParameters.getCollectionKeys(), rs, session );
       ...
       return results;
    
    }

    Así que no creo que se devolverá null ahora.

    • Saludos para la exacta fragmento de código. Pero esta respuesta se enfoca en hibernación, que es uno de la implementación de la especificación. Otra aplicación como OpenJPA difieren en el comportamiento. También, hibernate parece haber cambiado el comportamiento de las diferentes versiones.
  5. 1

    Por supuesto, si prueba que el conjunto de resultados con Yakarta CollectionUtils.isNotEmpty, usted está cubierto de cualquier manera.

  6. 0

    Query.getResultList() devuelve una lista vacía en lugar de null. A fin de comprobar isEmpty() en el resultado devuelto, y continuar con el resto de la lógica si es falso.

  7. 0

    Dada la implementación de getResultsList() en org.hibernate.ejb.QueryImpl de la clase, es posible devolver un null :

    public List getResultList() {
        try {
            return query.list();
        }
        catch (QueryExecutionRequestException he) {
            throw new IllegalStateException(he);
        }
        catch( TypeMismatchException e ) {
            throw new IllegalArgumentException(e);
        }
        catch (HibernateException he) {
            em.throwPersistenceException( he );
            return null;
        }

    Mi hibernación versión: 3.3.1.GA

Dejar respuesta

Please enter your comment!
Please enter your name here