— JUAN MIGUEL BERNAL GONZALEZ 2014/03/25 16:21
JavaEE 6 ha introducido una revisión de la capa de persistencia (Java Persistence API o JPA) que introduce algunas novedades. Quizás no suficientes para justificar el cambio de numeración mayor, pero quizás haya venido dado por el Criteria API, que ha sido un añadido bastante pretencioso que busca un código de mayor calidad quizás no para los desarrolladores sino para generadores automáticos de código. Ahora vamos a relatar las novedades de JPA 2.0 con respecto a JPA 1.0.
JPA 2.0 proporciona una interfaz Cache que puede obtenerse mediante el método getCache() de la clase EntityManagerFactory. La cache puede utilizarse para eliminar/invalidar manualmente entidades, clases completas y la cache al completo. También se puede comprobar si una entidad esta en la cache.
JPA 2.0 proporciona un conjunto de hints para las consultas para permitir refrescar o saltar la cache. Referencia y Ejemplos
JPA 2.0 define el mapeo de ElementCollection, que se utiliza para manejar mapeos de relaciones no estándar. Un ElementCollection se puede utilizar para definir una relación OneToMany con un objeto Embeddable o un valor Basic (como una colección de Strings).
Puede utilizarse junto a una columna Map para definir relaciones donde la clave es un tipo de objeto y el valor es un objeto Embeddable o valor Basic.
Los valores ElementCollection siempre se almacenan en una tabla separada, que se define con la anotación @CollectionTable. Esta anotación permite definir el nombre de la tabla y especificar la clave primaria mendiate las anotaciones @JoinColumn o si es compuesta mediante @JoinColumns. Referencia y Ejemplos
Permite que una relación que habitualmente se representaría como una lista pueda representarse como un mapa incluyendo como clave algunos valores de la tabla de destino (entre otros). Referencia y Ejemplos
JPA 2.0 defina una criteria API para consultas en un intento de simplificar la creación de consultas dinámicas. Con JPQL, las consultas dinámicas necesitan realizar concatenación de String. Además el JPQL es analizado en tiempo de ejecución provocando que los errores tipográficos se detecten más tarde. La criteria API utiliza un conjunto de interfaces Java para permitir que las consultas se construyan dinamicamente y permitiendo el análisis en tiempo de compilación. Referencia y Ejemplos
Una entidad huérfana, es aquella que es referenciado por una relación y que sin el valor de la fuente de la relación, su existencia no tiene sentido.
JPA 2.0 proporciona la opción orphanRemoval en las anotaciones @OneToMany y @OneToOne. La eliminación de huérfanos asegura que cualquier objeto que no sea referenciado por una relación es borrado de la base de datos. Referencia y Ejemplos
Tanto el EntityManager como la Query API has sido mejorados para soportar cosas como obtener el primer resultado (JPA 1.0 permitía obtener un único resultado), especificar el tamaño máximo del resultado, permitir acceder a los objetos query y entity manger específicos del motor de persistencia y el pessimistic locking (JPA 1.0 solo soporta optimistic locking). Entity Manager Updates
JPA 2.0 soporta pessimistic locking, que permite obtener un lock sobre un objeto que se quiere editar y evitar que otros usuarios puedan modificar el objeto. Referencia y Ejemplos - Tipos de Lock en JPA 2.0
JPQL ha sido mejorado con SQL-like CASE, NULLIF, COALESCE y funcionalidades like. Referencia y Ejemplos
JPA 2.0 añade soporte para la ordenación de listas de bean de entidad mediante la anotación @OrderColumn. Referencia y Ejemplos
JPA 1.0 no soporta relaciones OneToMany unidireccionales sin una JoinTable. JPA 2.0 añade soporte para relaciones OneToMany unidireccionales añadiendo la anotación @JoinColumn para especificar la clave foránea. Referencia y Ejemplos
JPA 2.0 permite definir dos tipos de acceso:
El tipo de acceso que usará una entidad está definido por el lugar donde situemos sus anotaciones de mapeo:
A efectos prácticos, no existe diferencia alguna entre ambas opciones (más allá de gustos personales y de organización de código). Sin embargo, en determinadas ocasiones debemos ser consecuentes con el tipo de acceso que elijamos, evitando mezclar tipos de acceso (lo cual puede inducir a JPA a actuar de forma errónea). Un ejemplo típico es el uso de clases insertables: salvo que se especifique lo contrario, las clases insertables heredan el tipo de acceso de la entidad donde son insertadas, ignorando cualquier anotación que se haga hecho sobre ellas previamente.