persistencia - Criterio de JPA/Consultas de CriteriaBuilder de la sesión de Hibernate

persistencia hibernate

Question

Tengo una aplicación que usa Hibernate 4.x, y actualmente está usando las API Hibernate nativas (lo que significa que tengo una SessionFactory y Session s). Me di cuenta de que la API Criteria existente está en desuso en favor de la API Criteria (superior) de JPA:

Hibernate ofrece una antigua API org.hibernate.Criteria heredada, que debe considerarse obsoleta. Ningún desarrollo de características se enfocará en esas API. Eventualmente, las características de los criterios específicos de Hibernate serán portados como extensiones de JPA javax.persistence.criteria.CriteriaQuery .

No quiero tener que convertir mi aplicación a usar EntityManager directamente (aunque es fácil obtener una Session Hibernate desde allí) porque tenemos una gran cantidad de lógica de configuración de Hibernate personalizada que tendrá que ser reemplazada. A pesar de eso, definitivamente quiero comenzar a utilizar las API de Criterios de JPA, ya que las antiguas API están en desuso (y probablemente desaparecerán en algún momento en el futuro, si las versiones pasadas de Hibernate son alguna indicación) y también proporcionan una seguridad de tipo mucho mejor.

¿Cómo puedo usar la nueva API CriteriaQuery / CriteriaBuilder, si estoy usando SessionFactory / Session?

Answer 1

Tenemos el mismo dilema en nuestro proyecto. El proyecto es realmente complicado: el 90% de las entidades se generan dinámicamente; hay un nivel de API implementado por encima de la API de criterios de Hibernate, DAO pesado y capa de servicio, que es muy amplio; nuestra versión hibernate está parcheada muchas veces para admitir funcionalidades específicas (como START WITH / CONNECT BY , ARRAY type in oráculo, etc.); postgresql y oracle se usan ambos, alternativamente, etc.

La nueva API de JPA nos sería muy útil. Necesitamos la capacidad de usar funciones en el nivel API de Criteria (no HQL) (como NVL/coalesce para algún tipo de razones de rendimiento, substring , trim , etc.). Además, necesitamos Hibernate Envers, que está disponible solo para la implementación de JPA " EntityManager ".

Desafortunadamente, de acuerdo con el resultado de nuestra investigación, no existe la posibilidad de utilizar la API de criterios JPA de Hibernate original. Envers no puede ser usado también. El proyecto Hibernate evoluciona continuamente y gana nuevas características. La migración a nuevas versiones de hibernación es una tarea muy complicada para nosotros. Y estamos muy preocupados por la incapacidad de utilizar muchas características nuevas de las nuevas versiones después de la migración y crecer con este marco básico.

Por lo tanto, consideramos dos maneras posibles para nosotros: usar SQLCriterion con implementación propia de Expression s (resolver nombres de columna con CriteriaQuery y traducir a SQL) o migrar a " EntityManager " / CriteriaBuilder . La segunda forma parece inevitable. Pero la migración a la implementación de JPA trae muchos problemas ocultos que arruinan nuestro proyecto.

Si elegimos la migración y será útil, dejaré aquí los problemas con los que lucharemos en esta actividad.