¿Cuáles son los pros y los contras de la utilización de Criterios de o HQL? Los Criterios API es un buen método orientado a expresar las consultas en modo de Hibernación, pero a veces los Criterios de las Consultas son más difíciles de entender y de construir que los HQL.

¿Cuándo el uso de los Criterios y cuando HQL? ¿Usted prefiere en el que los casos de uso? O es sólo una cuestión de gusto?

  • La respuesta correcta sería «depende del caso de uso’.
  • ¿Y qué acerca de esta herramienta? Se permite construir las consultas más comunes en un objeto: protegido de la Cláusula select() { return em.seleccione(«DISTINTO yo») .(esto.getName(), «i») .joinFetch(«yo.configuración regional lf») } public T findBySlug(Cadena slug) { return (T) esto.seleccione() .join(«yo.configuración regional l»); .donde(«l.slug = ?», slug) .fetchSingle(); }
  • Definición de una opinión basada en cuestión, sin embargo, la gente no ha tenido la oportunidad de cerrar … como por el sitio de preguntas frecuentes
InformationsquelleAutor cretzel | 2008-10-13

21 Comentarios

  1. 209

    Que en su mayoría prefieren los Criterios de las Consultas para consultas dinámicas. Por ejemplo, es mucho más fácil añadir algunos pedidos de forma dinámica o dejar algunas partes (por ejemplo, restricciones) dependiendo de algunos parámetros.

    Por otro lado estoy usando HQL para la estática y consultas complejas, porque es mucho más fácil de entender y leer HQL. También, HQL es un poco más potente, creo que, por ejemplo, para los diferentes tipos de combinación.

    • También, aunque los Criterios se ve un poco más seguro, la única cosa que puede hacer que se sienta seguro es la prueba.
    • Hay buenos ejemplos que muestran por qué HQL es mejor que la api de criterios en ciertos casos ? He leído el final de un blog, pero no entendía nada. Agradecería si le podía ayudar. Gracias. Enlace – javalobby.org/articles/hibernatequery102
    • Todas las razones anteriores – yo también prefiero los Criterios para HQL porque es más seguro para el programador, la disminución de los errores de codificación – compilación en el HQL cadena no está validado.
    • Sin embargo, hay la cuestión de la recuperación de distintas entidades, mientras que la paginación. Al hacer esto me quedaría con HQL para evitar problemas…
    • utilizando los criterios de la consulta con un metamodelo para la columna de los nombres de ayuda durante la refactorización para no romper nada y con un simple comando de un moderno IDE para cambiar el nombre de todas las apariciones en el código.
  2. 92

    Hay una diferencia en términos de rendimiento entre HQL y criteriaQuery, cada vez que el fuego de una consulta con criteriaQuery, se crea un nuevo alias para el nombre de la tabla que no se reflejan en la última consulta de caché para cualquier DB. Esto conduce a una sobrecarga de compilar el código SQL generado, teniendo más tiempo para ejecutar.

    Con respecto a estrategias de recuperación [http://www.hibernate.org/315.html]

    • Criterios respeta la pereza ajustes en sus asignaciones y garantiza que lo que desea cargar se carga. Esto significa que uno de los Criterios de consulta, podría resultar en varios SQL inmediata de las instrucciones SELECT para recuperar el subgrafo con todos los no-perezoso asignada asociaciones y colecciones. Si desea cambiar el «cómo» e incluso el «qué», el uso de setFetchMode() para habilitar o deshabilitar la combinación externa para la obtención de una colección particular o asociación. Los criterios de las consultas también completamente respecto a la estrategia de recuperación (unirse vs seleccione vs subselección).
    • HQL respeta la pereza ajustes en sus asignaciones y garantiza que lo que desea cargar se carga. Esto significa que una consulta HQL podría resultar en varios SQL inmediata de las instrucciones SELECT para recuperar el subgrafo con todos los no-perezoso asignada asociaciones y colecciones. Si desea cambiar el «cómo» e incluso el «qué», el uso de LEFT JOIN FETCH para habilitar exterior de la unión temprana para una colección particular o que aceptan valores null muchos-a-uno o uno-a-uno de la asociación, o JOIN FETCH para habilitar la combinación interna de la captura de una persona que no aceptan muchos-a-uno o uno-a-uno de la asociación. Consultas HQL no respetar ninguna fetch=»join» se define en el documento de mapeo.
  3. 41

    Criterios es una API orientada a objetos, mientras que HQL medio de la concatenación de cadenas. Eso significa que todos los beneficios de objeto-orientedness aplicar:

    1. Todo lo demás siendo igual, el OO versión es un poco menos propenso a errores. Cualquier cadena que podría conseguir que se anexa en la consulta HQL, mientras que los únicos Criterios válidos los objetos pueden convertirlo en un árbol de Criterios. Efectivamente, los Criterios de las clases son más limitados.
    2. Con auto-completado, el OO es más reconocible (y por lo tanto más fáciles de usar, al menos para mí). No necesariamente se debe recordar que las partes de la consulta donde ir, el IDE puede ayudar a
    3. Usted también no tiene que recordar los detalles de la sintaxis (como símbolos que ir a donde). Todo lo que usted necesita saber es cómo llamar a métodos y crear objetos.

    Desde HQL es muy parecida a la de SQL (que la mayoría de los desarrolladores saben muy bien ya), a continuación, estos «no tienen que recordar» los argumentos de no llevar demasiado peso. Si HQL era más diferente, entonces esto sería más importatnt.

    • Estos argumentos no se sostienen de agua (con respecto a HQL). Esto no tiene que ver con la concatenación de cadenas. Que la OO versión es menos propenso a errores es sin fundamento. Es igualmente propenso a errores, pero de un tipo diferente. El esfuerzo de saber qué métodos de la llamada no es mucho diferente de saber qué símbolos de llamada en HQL (quiero decir, en serio, no estamos de resolución de ecuaciones en derivadas parciales aquí.)
    • Hay buenos ejemplos que muestran por qué HQL es mejor que la api de criterios en ciertos casos ? He leído el final de un blog, pero no entendía nada. Agradecería si le podía ayudar. Gracias. Enlace – javalobby.org/articles/hibernatequery102
    • HQL consultas con nombre se compilan en el momento de la implementación y en este punto los campos que faltan (tal vez para mal refactors?) se detectan. Creo que esto hacer que el código sea más resistente y, de hecho, menos propenso a errores de criterios.
    • Auto-completar en Criterios es bastante inútil, ya que las propiedades son sólo cadenas.
  4. 35

    Que suelen utilizar Criterios, cuando no sé lo que las entradas se utilizará en el que las piezas de datos. Como en un formulario de búsqueda donde el usuario puede entrar en cualquiera de 1 a 50 puntos y no sé lo que va buscando. Es muy fácil agregar más a los criterios de como me vaya a través de la comprobación de lo que el usuario está buscando. Creo que sería un poco más difícil poner una consulta HQL en esa circunstancia. HQL es genial, aunque cuando yo sé exactamente lo que quiero.

    • Este es un buen comentario. Actualmente podemos construir muy grande HQL cadenas para un formulario de búsqueda que contiene muchos objetos diferentes a través de combinaciones. Se ve feo. Vamos a ver si un Criterio puede limpiar eso. Interesante…
    • Gracias. Este es un excelente ejemplo. Puede usted por favor darme más ?
  5. 31

    HQL es mucho más fácil de leer, fácil de depurar el uso de herramientas como el Eclipse, Hibernate plugin, y más fácil de registro. Los criterios de las consultas son mejores para la construcción de consultas dinámicas donde mucho se determina que el comportamiento en tiempo de ejecución. Si usted no sabe SQL, pude entender el uso de los Criterios de las consultas, pero en general yo prefiero HQL si sé lo que quiero por adelantado.

  6. 21

    Criterios Api es uno de los buenos concepto de Hibernación. según mi punto de vista estos son los pocos punto por el cual nos puede hacer la diferencia entre HQL y Criterios Api

    1. HQL es llevar a cabo ambos seleccionar y de no seleccionar las operaciones sobre los datos, pero los Criterios es sólo para la selección de los datos, no podemos realizar operaciones de selección mediante criterios.
    2. HQL es adecuado para la ejecución de Estática de Consultas, donde el Criterio es adecuado para la ejecución de Consultas Dinámicas
    3. HQL no admite la paginación concepto, pero podemos lograr la paginación con los Criterios.
    4. Criterios utilizados para tomar más tiempo en ejecutarse que HQL.
    5. Con Criterios que son seguros con de Inyección de SQL debido a su dinámica de generación de consultas, pero en HQL como sus dudas, ya sea fijo o parametrizadas, no hay seguro de la Inyección de SQL
    • Par de puntos de la Paginación es allí en HQL: puede utilizar limit offset:rows En hql puede evitar la inyección de código sql mediante setParameter
  7. 13

    Para mi Criterio es bastante fácil de Entender y realizar consultas Dinámicas. Pero el defecto que yo digo es que hasta ahora todas las cargas muchos-uno etc relaciones, porque sólo tenemos tres tipos de FetchModes yo.e Seleccione, y Proxy Predeterminado y en todos estos casos las cargas de muchos-uno (puede ser yo estoy equivocado, si es así me ayudan :))

    2ª edición con Criterios es que carga completa del objeto.e si quiero cargar EmpName de un empleado no llegar a este lugar se van a plantear con total Empleado objeto y puedo conseguir EmpName de ella debido a este funciona realmente mal en la presentación de informes. donde como HQL sólo carga (¿no carga la asociación/relaciones) lo que u quieres aumentar el rendimiento muchas veces.

    Una característica de los Criterios es que seguro u de la Inyección de SQL, debido a su dinámica de generación de consulta donde como en HQL como ur consultas son fijos o parametrizar de forma no segura de la Inyección de SQL.

    También, si usted escribe HQL en ur aspx.cs, a continuación, que están estrechamente vinculadas con ur DAL.

    En general, mi conclusión es que hay lugares donde la u no puede vivir sin HQL como los informes, así que otro de los Criterios es más fácil de manejar.

    • Consultas HQL son la inyección de SQL seguro…
    • HQL NO es la inyección de SQL seguro
    • Creo que los Criterios no es de inyección segura. Ver mi post aquí: stackoverflow.com/questions/6746486/…
    • HQL ES la inyección de sql seguro mediante la adición de ‘setParameter’
    • puede seleccionar sólo ciertas propiedades de una entidad que utiliza las proyecciones de
    • puede establecer la proyección en la consulta de criterios para seleccionar las columnas particulares. Usted puede obtener EmpName, no hay necesidad de buscar objeto completo.

  8. 12

    A utilizar lo mejor de ambos mundos, la expresividad y la concisión de HQL y la naturaleza dinámica de los Criterios que considere la posibilidad de usar Querydsl.

    Querydsl apoya JPA/Hibernate, JDO, SQL y Colecciones.

    Yo soy el mantenedor de Querydsl, por lo que esta respuesta es parcial.

  9. 11

    Para mí el mayor premio de los Criterios es el Ejemplo de la API, donde se puede pasar un objeto y hibernate crear una consulta basada en aquellas propiedades de los objetos.

    Además de eso, los criterios de la API tiene sus peculiaridades (creo que el equipo hibernate es la remodelación de la api), como:

    • un criterio.createAlias(«obj») de las fuerzas de un inner join en lugar de una posible combinación externa
    • no se puede crear el mismo alias dos veces
    • algunas cláusulas sql no tienen criterios simples contraparte (como una subselección)
    • etc.

    Que tienden a usar HQL cuando quiero consultas similares a sql (delete from users where estado=’bloqueado’), y que tienden a utilizar criterios cuando no quiero usar la cadena de anexar.

    Otra ventaja de HQL es que se puede definir a todas sus consultas antes de la mano, e incluso de externalizar a un archivo o así.

  10. 10

    Criterios API es más adecuado para las consultas generadas dinámicamente cuando los filtros de consulta se aplica de forma dinámica en tiempo de ejecución. Por lo tanto, para prevenir los ataques de Inyección SQL al edificio de consultas dinámicas, los Criterios API es una muy buena opción.

    Criterios de las consultas son menos expresivos y puede acabar fácilmente con una muy complicado e ineficiente SQL generado por la consulta. Yo una vez se unió a una aplicación de gran empresa, donde los Criterios API era el método de consulta y ni siquiera extenso código de revisar podría superar el horror de no saber qué consultas SQL íbamos a terminar para arriba.

    JPQL o HQL es mucho más expresivo, y es mucho más fácil predecir el que se generan de la consulta SQL. También es mucho más fácil revisar una de las consultas HQL de Criterios queridos.

    La mayoría de la entidad de consulta de casos de uso no requieren dinámica en la que las cláusulas de modo que usted puede aplicar a la mayoría de las consultas JPQL dejando Criterios para las dinámicas.

    Vale la pena señalar que la selección de las entidades con JPQL o los Criterios de la API de sentido si usted necesita para modificarlos. De lo contrario, un DTO de proyección funciona mejor. Echa un vistazo este artículo para obtener más información.

  11. 9

    Criterios de la api de proporcionar una característica distinta que Ni SQL o HQL proporciona. es decir. permite compilar el tiempo de la comprobación de una consulta.

  12. 7

    Hemos utilizado principalmente Criterios en la aplicación en el principio, pero después fue reemplazado con HQL debido a los problemas de rendimiento.

    Principalmente estamos usando consultas muy complejas con varias combinaciones que conduce a varias consultas en Criterios, pero está muy optimizado en HQL.

    El caso es que sólo usamos varios propeties en objeto específico y no incluye los objetos. Con los Criterios que el problema era también la concatenación de cadenas.

    Digamos que si usted necesita para mostrar el nombre y apellidos del usuario en HQL es muy fácil (name || ' ' || surname) pero en Crteria esto no es posible.

    Para superar esto, utilizamos ResultTransormers, donde existían métodos donde tal concatenación fue implementado para el resultado necesario.

    Hoy en día utilizamos principalmente el HQL como este:

    String hql = "select " +
                "c.uuid as uuid," +
                "c.name as name," +
                "c.objective as objective," +
                "c.startDate as startDate," +
                "c.endDate as endDate," +
                "c.description as description," +
                "s.status as status," +
                "t.type as type " +
                "from " + Campaign.class.getName() + " c " +
                "left join c.type t " +
                "left join c.status s";
    
    Query query =  hibernateTemplate.getSessionFactory().getCurrentSession().getSession(EntityMode.MAP).createQuery(hql);
    query.setResultTransformer(Transformers.ALIAS_TO_ENTITY_MAP);
    return query.list();

    por lo que en nuestro caso los registros devueltos son los mapas de las propiedades necesarias.

    • Con los Criterios que se pueden utilizar org.hibernate.criterio.CriteriaSpecification.ALIAS_TO_ENTITY_MAP
    • Devuelve una lista de los mapas en mi experiencia tiene un muy mal rendimiento. Yo prefiero devolver una lista de objetos arrays o listas de frijoles (siempre se puede definir un bean que se adapte a sus específicos conjunto de resultados).
  13. 7
    • HQL es llevar a cabo ambos seleccionar y de no seleccionar las operaciones sobre los datos, pero los Criterios es sólo para la selección de los datos, no podemos realizar operaciones de selección mediante criterios
    • HQL es adecuado para la ejecución de Estática de Consultas, donde el Criterio es adecuado para la ejecución de Consultas Dinámicas
    • HQL no admite la paginación concepto, pero podemos lograr la paginación con Criterios
    • Criterios utilizados para tomar más tiempo para ejecutar, a continuación, HQL
    • Con Criterios que son seguros con la Inyección de SQL, debido a su dinámica de generación de consultas, pero en HQL como sus dudas, ya sea fijo o parametrizadas, no hay seguro de la Inyección de SQL.

    fuente

    • Para aclarar, los criterios de las consultas usando Hibernate Criterios del API puede estar disponible para la consulta, pero JPA consultas de criterios cubrir selecciona, actualizaciones y eliminaciones. Ver CriteriaUpdate<T> y CriteriaDelete<T> de referencia.
  14. 5

    Criterios de consulta para dinámicamente podemos construir consulta basada en nuestras entradas..En caso de consulta Hql es la estática de la consulta una vez que construimos nosotros no podemos cambiar la estructura de la consulta.

    • No es así. Con HQL puede establecer las propiedades con el ‘:’ identificador y, a continuación, reemplazar las propiedades con valores únicos. Por ejemplo, la Consulta q = período de sesiones.createQuery(«SELECT :aValue DE my_table»); y, a continuación, q.setParameter(«aValue», «some_column_name»);
    • En su ejemplo, usted está cambiando valores de los parámetros, no en la estructura de la consulta.
  15. 4

    No quiero patada de un caballo muerto aquí, pero es importante mencionar que los Criterios de las consultas están ahora en desuso. Uso HQL.

  16. 1

    Yo también prefiero los Criterios de las Consultas para consultas dinámicas. Pero yo prefiero hql para consultas de eliminación, por ejemplo, si elimina todos los registros de la tabla padre id ‘xyz’, es fácil de lograr por HQL, pero para los criterios de la API en primer lugar, debemos fuego n el número de consulta de eliminación, donde n es el número de niños registros de la tabla.

  17. 0

    La mayoría de las respuestas aquí son engañosas y mencionar que Criteria Queries son más lentos que HQL, que en realidad no es el caso.

    Si profundizamos y realizar algunas pruebas verá Consultas de Criterios de realizar mucho mejor que regular HQL.

    Y también con Criterios de Consulta usted obtener Orientado a Objetos de control que no existe en los HQL.

    Para obtener más información, lea esta respuesta aquí.

    • ¿Por qué el downvote?
  18. 0

    Hay otra manera. Terminé con la creación de un HQL analizador basado en hibernación original de la sintaxis por lo que primero analizar el HQL, entonces podría dinámicamente inyectar parámetros dinámicos o de forma automática, añadiendo algunos filtros comunes para las consultas HQL. Funciona a la perfección!

  19. 0

    Este post es bastante antiguo. La mayoría de las respuestas a hablar de Hibernación criterios, no JPA criterios. JPA 2.1 añadido CriteriaDelete/CriteriaUpdate, y EntityGraph que controla exactamente lo fuera a buscar. Criterios de API es mejor, ya que Java es OO. Es por eso que JPA es creado. Cuando JPQL es compilado, será traducido a AST árbol(O modelo) antes de traducir a SQL.

  20. -3

    HQL puede causar de seguridad preocupaciones como la inyección SQL.

    • Estos problemas no son causados por HQL, pero por la falta de comprensión básica de prácticas de desarrollo de software. Puedo crear código propenso a ataques de inyección sql con los criterios de la api igual de bien.
    • Es como decir: «consulta de un RDBMS de Java puede causar la inyección de SQL preocupaciones de seguridad» 😀

Dejar respuesta

Please enter your comment!
Please enter your name here