Persistencia en Yakarta

Este artículo necesita citas adicionales para su verificación . Por favor, ayude a mejorar este artículo añadiendo citas de fuentes fiables . El material sin fuentes puede ser cuestionado y eliminado. Buscar fuentes:  «Jakarta Persistence» – noticias  · periódicos  · libros  · académico  · JSTOR ( junio de 2010 ) ( Aprenda cómo y cuándo eliminar este mensaje )

Jakarta Persistence , también conocida como JPA (abreviatura del nombre anterior Java Persistence API ), es una especificación de interfaz de programación de aplicaciones Jakarta EE que describe la gestión de datos relacionales en aplicaciones Java empresariales .

La persistencia en este contexto abarca tres áreas:

• La API en sí, definida en el jakarta.persistencepaquete ( javax.persistencepara Jakarta EE 8 y versiones anteriores)
• El lenguaje de consulta de persistencia de Jakarta (JPQL; anteriormente Java Persistence Query Language)
• Metadatos relacionales/de objeto

La implementación de referencia para JPA es EclipseLink . ^[1]

La fecha de publicación final de la especificación JPA 1.0 fue el 11 de mayo de 2006 como parte del Java Community Process JSR 220. La especificación JPA 2.0 se publicó el 10 de diciembre de 2009 (la plataforma Java EE 6 requiere JPA 2.0 ^[2] ). La especificación JPA 2.1 se publicó el 22 de abril de 2013 (la plataforma Java EE 7 requiere JPA 2.1 ^[3] ). La especificación JPA 2.2 se publicó en el verano de 2017. La especificación JPA 3.1, la última versión, se publicó en la primavera de 2022 como parte de Jakarta EE 10. ^[1]

Una entidad persistente es una clase Java liviana cuyo estado generalmente se conserva en una tabla en una base de datos relacional . Las instancias de una entidad de este tipo corresponden a filas individuales en la tabla. Las entidades generalmente tienen relaciones con otras entidades y estas relaciones se expresan a través de metadatos de mapeo relacional/objeto (ORM). Estos metadatos se pueden especificar directamente en el archivo de clase de entidad mediante anotaciones o en un archivo descriptor XML separado distribuido con la aplicación.

Una clase de entidad de ejemplo con metadatos ORM declarados mediante anotaciones (las declaraciones de importación y los establecedores/obtenedores se omiten para simplificar).

@Entity clase pública Persona { @Id id largo privado ; String nombre privado ; String apellido privado ; int edad privado ; }                

La @Entityanotación declara que la clase representa una entidad. @IdDeclara el atributo que actúa como clave principal de la entidad. Se pueden utilizar anotaciones adicionales para declarar metadatos adicionales (por ejemplo, cambiar el nombre de tabla predeterminado en la @Tableanotación) o para crear asociaciones entre entidades.

El lenguaje de consulta persistente de Jakarta (JPQL, anteriormente Java Persistence Query Language) realiza consultas sobre entidades almacenadas en una base de datos relacional. Las consultas se parecen a las consultas SQL en sintaxis, pero operan sobre objetos de entidad en lugar de hacerlo directamente sobre tablas de base de datos.

Antes de la introducción de la especificación EJB 3.0, muchos desarrolladores de Java empresariales utilizaban objetos persistentes ligeros proporcionados por marcos de persistencia (como Hibernate ) u objetos de acceso a datos (DAO) en lugar de utilizar beans de entidad . Esto se debe a que los beans de entidad, en especificaciones EJB anteriores, exigían un código mucho más complicado e imponían una gran huella de recursos, y solo se podían utilizar en servidores de aplicaciones Java EE debido a las interconexiones y dependencias en el código fuente entre los beans y los objetos DAO o los marcos de persistencia. Por lo tanto, muchas de las características presentadas originalmente en marcos de persistencia de terceros se incorporaron a la API de persistencia de Java, y proyectos como Hibernate y TopLink Essentials se han convertido en implementaciones de la especificación de la API de persistencia de Java.

La especificación EJB 3.0 (que forma parte de la plataforma Java EE 5) incluía una definición de la API de persistencia de Java. Sin embargo, los desarrolladores no necesitan un contenedor EJB ni un servidor de aplicaciones Java EE para ejecutar aplicaciones que utilicen esta API de persistencia. ^[4] Las versiones futuras de la API de persistencia de Java se definirán en un JSR y una especificación independientes, en lugar de en el JSR/especificación de EJB.

La API de persistencia de Java reemplaza la solución de persistencia de EJB 2.0 CMP (Container-Managed Persistence).

La API de persistencia de Java se desarrolló en parte para unificar la API de objetos de datos de Java y la API de persistencia administrada por contenedores (CMP) de EJB 2.0. La mayoría de los productos que admiten cada una de las dos API son compatibles con la API de persistencia de Java.

La API de persistencia de Java especifica la persistencia solo para sistemas de administración de bases de datos relacionales , centrándose en el mapeo relacional de objetos (ORM). Algunos proveedores de JPA admiten otros modelos de bases de datos , aunque esto está fuera del alcance del diseño de JPA. La sección de introducción de la especificación de JPA establece: "El objetivo técnico de este trabajo es proporcionar una función de mapeo relacional de objetos para el desarrollador de aplicaciones Java que utilice un modelo de dominio Java para administrar una base de datos relacional". ^[5]

La especificación de objetos de datos de Java admite ORM, así como la persistencia en otros tipos de modelos de bases de datos, por ejemplo, bases de datos de archivos planos y bases de datos NoSQL , incluidas bases de datos de documentos , bases de datos de gráficos y muchos otros almacenes de datos.

Los diseñadores ^[6] de la API de persistencia de Java apuntaron a proporcionar persistencia relacional, con muchas de las áreas clave tomadas de herramientas de mapeo relacional de objetos como Hibernate y TopLink . La API de persistencia de Java mejoró y reemplazó a EJB 2.0, evidenciado por su inclusión en EJB 3.0. La API de objetos de datos de servicio (SDO) (JSR 235) tiene un objetivo muy diferente al de la API de persistencia de Java y se considera ^{[7] [8]} complementaria. La API de SDO está diseñada para arquitecturas orientadas a servicios , múltiples formatos de datos en lugar de solo datos relacionales y múltiples lenguajes de programación. El Proceso de la comunidad Java administra la versión Java de la API de SDO; la versión C++ de la API de SDO se administra a través de OASIS .

Hibernate, fundada por Gavin King, proporciona un marco de mapeo relacional de objetos de código abierto para Java . Las versiones 3.2 y posteriores proporcionan una implementación para la API de persistencia de Java. ^{[9] [10]} King representó a JBoss en JSR 220, ^[11] el grupo de expertos de JCP encargado de desarrollar JPA. Esto llevó a una controversia y especulación continuas en torno a la relación entre JPA e Hibernate. ^{[ cita requerida ]} Sun Microsystems declaró ^[12] que las ideas provenían de varios marcos, incluidos Hibernate y Java Data Objects .

Spring Data JPA es una implementación de la abstracción de repositorio que es un componente fundamental del diseño orientado al dominio basado en el marco de aplicaciones Java Spring . Admite de forma transparente todas las implementaciones de JPA disponibles y admite operaciones CRUD , así como la ejecución conveniente de consultas de bases de datos. ^{[13] : 47  [14]}

El desarrollo de una nueva versión de JPA 2.0 se inició en julio de 2007 en el Proceso de la Comunidad Java como JSR 317. JPA 2.0 fue aprobado como final el 10 de diciembre de 2009. El objetivo de JPA 2.0 era abordar características que estaban presentes en algunos de los proveedores de ORM populares pero que no pudieron obtener la aprobación de consenso para JPA 1.0.

Las principales características incluidas fueron:

• Funcionalidad ampliada de mapeo relacional de objetos
  • Soporte para colecciones de objetos incrustados, vinculados en el ORM con una relación de muchos a uno
  • Listas ordenadas
  • Combinaciones de tipos de acceso
• Una API de consulta de criterios
• Estandarización de sugerencias SQL
• Estandarización de metadatos adicionales para respaldar la generación de DDL
• Soporte para validación
• Soporte de caché de objetos compartidos.

Proveedores que admiten JPA 2.0:

• Asociación de Policía de Batoo
• DataNucleus (anteriormente JPOX)
• EclipseLink (anteriormente Oracle TopLink )
• IBM , para el servidor de aplicaciones WebSphere ^[15]
• JBoss con Hibernate
• Base de datos de objetos
• OpenJPA
• OrientDB
• Versant Corporation JPA ( base de datos de objetos ) ^[16]

El desarrollo de la versión 2.1 de JPA comenzó en julio de 2011 como JSR 338. JPA 2.1 fue aprobada como final el 22 de mayo de 2013.

Las principales características incluidas fueron:

• Convertidores, que permiten conversiones de código personalizadas entre tipos de objetos y bases de datos
• Actualización/eliminación de criterios para permitir actualizaciones y eliminaciones masivas a través de la API de criterios
• Gráficos de entidades para la obtención o fusión parcial o especificada de objetos.
• Mejoras de JPQL/Criterios como subconsultas aritméticas, funciones de base de datos genéricas, cláusula de unión ON y la opción TREAT.
• Generación de esquemas
• Soporte para procedimientos almacenados

Proveedores que admiten JPA 2.1:

• Núcleo de datos
• Enlace Eclipse
• Hibernar
• OpenJPA (a partir de la versión 2.2.0)

El desarrollo de JPA 2.2, una versión de mantenimiento, comenzó en 2017 según JSR 338. La revisión de mantenimiento se aprobó el 19 de junio de 2017.

Las principales características incluidas fueron:

• La adición de @Repeatable a todas las anotaciones relevantes
• Compatibilidad con anotaciones JPA para su uso en metaanotaciones
• Transmisión de resultados de consultas
• La capacidad de los AttributeConverters de ser inyectables mediante CDI
• Compatibilidad con los tipos de fecha y hora de Java 8

Proveedores que admiten JPA 2.2:

• DataNucleus (a partir de la versión 5.1)
• EclipseLink (a partir de la versión 2.7)
• Hibernar (a partir de la versión 5.3)
• OpenJPA (a partir de la versión 3.0)

En 2019, el JPA pasó a llamarse Jakarta Persistence y en 2020 se lanzó la versión 3.0. Esto incluyó el cambio de nombre de los paquetes y propiedades de javax.persistence a jakarta.persistence.

Proveedores que admiten Jakarta Persistence 3.0:

• DataNucleus (a partir de la versión 6.0)
• EclipseLink (a partir de la versión 3.0)
• Hibernar (a partir de la versión 5.5)
• OpenJPA (a partir de la versión 4.0)

La versión 3.1 se lanzó en 2022. ^[1] Es parte de Jakarta EE 10 y, por lo tanto, requiere al menos Java 11 para ejecutarse. Agrega un mejor manejo de UUID, varias funciones JPQL nuevas para matemáticas y manejo de fecha/hora, y otros pequeños cambios. ^[17]

Proveedores que admiten Jakarta Persistence 3.1:

• DataNucleus (a partir de la versión 6.0)
• EclipseLink (a partir de la versión 4.0) ^[18]
• Hibernación (a partir de la versión 6.0) ^[19]
• OpenJPA (a partir de la versión 4.0)

• API de persistencia de .NET (NPA)
• JDBC

• Deinum, Marten; Rubio, Daniel; Long, Josh; Mak, Gary (1 de septiembre de 2014). Recetas de primavera: un enfoque de solución de problemas (segunda edición). Apress . ISBN 978-1-4302-2499-0.

Wikilibros tiene un libro sobre el tema: Persistencia de Java

• Sitio web oficial
• Documentación para la versión final de la especificación EJB3 (llamada JSR220)
• Página de persistencia de GlassFish Archivado el 12 de enero de 2013 en archive.today
• Página de persistencia de JCP

• Javadoc de API de persistencia de Java EE 6
• Tutorial de la API de persistencia de Java EE 6
• Javadoc de API de persistencia de Java EE 7
• Tutorial de la API de persistencia de Java EE 7
• Persistencia en el tutorial de Java EE 5