Java persitence api

Framework JPA Página 1
Indice
Indice ......................................................................................................................................1
Introducción............................................................................................................................2
Frameworks de Persistencia ...................................................................................................3
Persistencia:........................................................................................................................3
Java Persistence: Definiciones................................................................................................4
Anotaciones ........................................................................................................................5
Arquitectura........................................................................................................................5
Ciclo de Vida de una Entidad .............................................................................................6
Problemas de JPA ...............................................................................................................6
Implementaciones JPA........................................................................................................7
Cómo Funciona JPA ...........................................................................................................7
Consultas: ...........................................................................................................................9
Recomendaciones.................................................................................................................20
Conclusiones.........................................................................................................................21
Egrafias.................................................................................................................................22

Introducción
Este documento le proporcionara al lector los conceptos básicos e intermedios del
framework JPA, definimos primero que es un framework en términos generales lo
podemos definir como un conjunto estandarizado de conceptos, practicas y criterios.
Framework en lenguaje de programación lo definimos como una estructura conceptual y
tecnológica, este se pueden incluir como soporte de programas y bibliotecas.
El Framework JPA es un framework de persistencia. Se define como persistencia porque
puede almacenar datos de una aplicación en un medio físico como una base de datos, un
archivo de texto, etc. Este framework lo orientamos al lenguaje de programación JAVA,
existen varios frameworks para este lenguaje, sin embargo vamos a hablar de Java
Persistence Api por sus siglas JPA, este framework fue desarrollado por java EE. Este
framework maneja datos relacionales en aplicaciones usando la plataforma Java en sus
ediciones Standard y Enterprise.
Como funciona el framework JPA, este abstrae de la base de datos y brinda un estándar
para persistir el dato en java, este framework soluciona el vacío que hay entre utilizar
objetos y persistirlos en una base de datos relacional. (Ver pagina 7).
El objetivo principal de Java Persistence es no perder las ventajas de la orientación a
objetos al interactuar con una base de datos. JPA ha combinado ideas y conceptos de los
principales frameworks de persistencia, como Hiberante, Toplink y jDO. Ademas en este
documento hablamos de la arquitectura y el ciclo de vida.

Java Persitence API (JPA)
Frameworks de Persistencia
Persistencia:
Por persistencia se entiende almacenar los datos de una aplicación en un medio físico
como una base de datos, un archivo de texto, etc.
Un framework de persistencia es una API que permite almacenar datos; los soportes de
almacenamiento son variados, desde ficheros hasta bases de datos.
En Java se han utilizado diversos frameworks de persistencia:
JDBC
Enterprise Java Beans: el estándar EJB 2.0 define un tipo de bean llamado Entity
Bean, el cual puede ser persistido por el servidor de aplicaciones. Se definió EJBQ
QL como lenguaje neutro de acceso a datos. Muy complejo de configurar
Java Data Objects: mucho más simple a EJB 2.0 y surge como alternativa a éste,
aunque nunca llegó a formar parte del estándar.
Los desarrolladores buscaron fuera del estándar frameworks de persistencia fáciles de
utilizar y fuertemente implantados en el mercado ejemplos de esto son:
Toplink: con licencia comercial
Hibernate: OpenSource y ampliamente difundido
El grupo de trabajo dentro de EJB 2.0 decidió estandarizar estas APIs, dando como
resultado la definición 3.0 de EJB, el cual incluye una serie de interfaces que definen el
estándar de Persistencia en Java: Java Persistence API o JPA
La gran mayoría de los frameworks existentes hasta el momento ofrecen una
implementación de dicho estándar

Java Persistence: Definiciones
JPQL: El lenguaje de consultas JPQL recuerda en su forma al SQL estándar, pero en
lugar de operar sobre tablas de la base de datos lo hace sobre entidades.
POJO: Plain Old Java Object → clases que no extienden a ninguna otra: MyDb.java
es POJO, NewPostServlet no es POJO
Entidad: Objeto con las anotaciones adecuadas para realizar la persistencia a la
BBDD.
Anotación: Añadir metadatos (datos descriptivos) al código fuente.
NativeQuery: Consultas en SQL Nativo que se traducen a objetos entidad.
Java Persistence API, más conocida por sus siglas JPA, es la API de persistencia desarrollada
para la plataforma Java EE
Es un framework del lenguaje de programación Java que maneja datos relacionales en
aplicaciones usando la Plataforma Java en sus ediciones Standard (Java SE) y Enterprise
(Java EE).
La JPA fue originada a partir del trabajo del JSR 220 Expert Group. Ha sido incluida en el
estándar EJB3.
Persistencia en este contexto cubre tres áreas:
La API en sí misma, definida en el paquete javax.persistence
El lenguaje de consulta Java Persistence Query Language (JPQL).
Metadatos objeto/relacional.
El objetivo que persigue el diseño de esta API es no perder las ventajas de la orientación a
objetos al interactuar con una base de datos (siguiendo el patrón de mapeo objeto-
relacional), como sí pasaba con EJB2, y permitir usar objetos regulares (conocidos
como POJOs).
En su definición, ha combinado ideas y conceptos de los principales frameworks de
persistencia, como Hibernate, Toplink y JDO, y de las versiones anteriores de EJB. Todos
estos cuentan actualmente con una implementación JPA.
El mapeo objeto-relacional (es decir, la relación entre entidades Java y tablas de la base de
datos, quieres con nombre, etc.) se realiza mediante anotaciones en las propias clases de
entidad. No se requieren ficheros descriptores XML. También pueden definirse
transacciones como anotaciones JPA.

Anotaciones
Las anotaciones de JPA se clasifican en dos categorías:
Mapeo Lógico:
Permiten describir modelo de objeto, asociaciones de clase, etc.@OneToOne,
OneToMany, etc
Mapeo Físico:
Describen esquemas físicos de base de datos, tablas, columnas, índices, etc.
Arquitectura
El siguiente diagrama muestra la relación entre los componentes principales de la
arquitectura de JPA:

Ciclo de Vida de una Entidad
Características Importantes de JPA
JPA es un framework de persistencia Java, ligera y basada en POJOs o Beans.
Permite definir el mapeo objeto-relacional aunque también ofrece soluciones
arquitecturales para integrar la persistencia en aplicaciones que requieran alta
escalabilidad
Define un lenguaje que permite lanzar consultas sobre las entidades y sus
relaciones, basado en EJB QL, llamado Java Persistence Query Language o JPQL
La configuración se realiza con un pequeño fichero XML y las relaciones o
metadatos de las entidades se definen mediante anotaciones en las propios Beans
(aunque también se pueden definir en el fichero XML anterior
Por qué usar JPA
Facilita la persistencia desde el punto de vista del desarrollador.
Encapsula el uso de SQL, JDBC y otras tecnologías subyacentes.
Incrementa la respuesta al cambio de las aplicaciones.
No requiere de un servidor de aplicaciones para su uso.
Reducción dramática en código de acceso a datos.
Permite concentrarse en el modelo de objeto y no en el modelo de datos.
Problemas de JPA
Incrementa el uso de recursos para el acceso a datos, ya que agrega elementos por
encima de JDBC para mejorar su eficiencia.
Ofrece nuevos retos en cuanto a manejo de Caches y concurrencia.
Abstrae de tan alto nivel de persistencia que las optimizaciones de DBMS no se
implementan fácilmente.
No implementa el uso de StoredProcedures, pero por medio de NativeQuery se
puede realizar la invocación.

Implementaciones JPA
En el mercado hay varios proveedores para el API de JPA:
Hibernate.
OpenJPA.
Oracle TopLink.
JPOX
CocoBase
EclipseLink
Amber
Si se respeta el uso de las anotaciones estándar, la solución puede ser interoperable entre
proveedores sin cambios traumáticos.
Cómo Funciona JPA
JPA es un framework de persistencia, que nos abstrae de las bases de datos y nos brinda
un estándar para persistir los datos en java. JPA viene a solucionar el vacío que hay entre
utilizar objetos y persistirlos en una DB relacional. ¿Como todos sabemos java trabaja con
el paradigma orientado a objetos, pero que pasa cuando quiero guardar mis datos?
Podría utilizar DB orientadas a objetos, pero con el tiempo estas no han podido imponerse
a las relacionales, cuyo punto fuerte es SQL, un estándar para la consultas. JPA mapea
automáticamente nuestras clases en la base de datos de manera transparente, y utilizando
un estándar, lo cual entre otras cosas nos permite poder migrar de motor cuando
queramos, y poder compartir código o trabajar en equipo sin ningún problema.
JPA trabaja fuertemente con anotaciones. Para mapear un bean (una clase java) con una
tabla de la base de datos, tendríamos que escribir lo que se llama un Entity. Esto es tan
sencillo como escribir nuestro Bean, con sus atributos y métodos get y set. Y después
añadirle la anotación “@Entity” a la par que seleccionamos uno de sus atributos como
clave primaria con “@Id”.
Por ejemplo, el siguiente trozo de código podría ser un Entity, que nos permitiría luego
almacenar, recuperar, o actualizar campos sobre una tabla “usuario”:
@Entity
public class Usuario
{
@Id
private String id;

private String name;
private String email;
}
Con solo esto ya tenemos creada una “entidad” llamada “Usuario” y podríamos insertar,
actualizar o eliminar entradas en una tabla llamada “Usuario” aunque esta aún no existe,
siquiera.
Un fichero muy importante que tenemos que crear a parte de las clases “Entity” es el
fichero “persistence.xml”, en este fichero vamos a indicar precisamente que clases son
Entity, sobre qué base de datos vamos a atacar, y cuál es la política de creación de esta
base de datos.
Este fichero tiene los datos de la conexión a la base de datos, la cual ya debe estar creada
anteriormente. En el caso de las tablas no es necesario, JPA automáticamente crea las
tabas necesarias a partir de las entidades que poseamos (en caso que tengamos habilitada
dicha característica).
El fichero xml se estructura de la siguiente forma:
Tiene un nombre “EjemploPU” en el tag , este es importante, pues luego es por ese
nombre por el que podremos acceder a este recurso o unidad de persistencia. Aquí
se llama “EjemploPU” pero puedes darle el nombre o alias que quieras.
Entre y vamos añadiendo todas las clases Entity que queremos manipular. Esto
también es muy importante, porque si creas un Entity pero no lo añades a esta
sección del XML, para JPA no existe.
Y por último están los properties. En estos properties estamos definiendo el
mecanismo de conexión a la base de datos. Cambiando estos valores por los
adecuados podemos conectar a cualquiera otra base de datos que tengamos.
Existe una última propiedad que conviene tener activa en los primeros momentos,
cuando estamos desarrollando:
Esta propiedad hace que si el modelo de datos no existe se cree de manera automática,
pero cada vez que invocamos al mecanismo de persistencia, borra el contenido de las
tablas y las vuelve a crear si no existen previamente. Esto al comienzo cuando estamos de
“pruebas” viene de fábula, después ya podemos comentar esta opción para trabajar con
datos reales que tengamos insertados.
Tenemos los Entity ya creados. Como puedo por ejemplo, insertar uno de ellos en la base
de datos.
Pues con un trozo de código similar al siguiente:
- Primero creamos un EntityManager que nos permita manipular y trabajar con los objeto
Entity:

EntityManagerFactory factory = Persistence.createEntityManagerFactory("EjemploPU",
System.getProperties());
em = factory.createEntityManager();
Como se puede ver, el nombre que uso es “EjemploPU”, esto es porque asi lo tenemos
definido en el fichero “persistence.xml”, así sabe cómo recuperar las clases y propiedades
que corresponden a esta unidad de persistencia. Si tu cambiaste el nombre en el XML,
aquí deberías poner el que hayas usado.
Una vez creada la EntityManager, ya es muy simple, abrir una transacción e incluso
almacenar elementos (Entity) en la base de datos. Un ejemplo para insertar un “Usuario”
podría ser:
em.getTransaction().begin();
Usuario u = new Usuario();
u.setId(100);
u.setName("jose");
u.setEmail("notengo@gmail.com");
em.persist(u);
em.flush();
em.getTransaction().commit();
Como se puede ver, hemos recuperado una transacción (getTransaction), instanciado un
objeto usuario, asignado valores a sus atributos, lo hemos “persistido” (almacenado) en la
base de datos con “persist” y por ultimo un commit de la transacción.
Es decir, solo escribiendo una clase, y un XML, ya hemos insertado un usuario con campos
nombre y email en una tabla “Usuarios” que se ha generado de manera dinámica. ¿No te
parece ideal?.
No hay que escribir métodos, insert, update ni delete, ni crear el modelo de la tabla si no
nos interesa. Todo se hace dinámicamente.
Consultas:
Para hacer las consultas en JPA se emplea un lenguaje denominado JPQL, no es SQL
exactamente porque trabaja con “objetos” no con “columnas” pero si muy parecido.
Por ejemplo, si la consulta de todos los campos de una tabla es “SELECT * FROM
USUARIOS”, en JPQL la consulta seria “SELECT u FROM Usuario u”, Donde “Usuario” no es
el nombre de una tabla, sino de la clase “Entity” y “u” son los identificadores del objeto.
Más ejemplos: “SELECT u.id,u.name FROM Usuario u where u.name LIKE := PARAMETRO”.

Es muy parecido a construir un PreparedStatement donde pasamos los parámetros. Para
ejecutar estas consultas empleamos el objeto “Query”. Query admite dos métodos:
getResultList, cuando el conjunto de valores devuelto es una lista de valores, por
ejemplo un SELECT de varios campos.
getSingleResult, cuando solo se devuelve un único objeto (fila).
Por ejemplo para obtener Todos los clientes de una tabla “Clientes”:
Query q = em.createQuery("SELECT c FROM Cliente c");
List<Cliente> clientes= q.getResultList();
intnum_clientes= clientes.size();
Si quisiéramos ejecutar consultas con parámetros, las variables a sustituir van precedidas
de “:” y debemos pasarlas con setParameter. Ejemplo: una consulta de Clientes cuyo id es
“666″ seria:
Query q = em.createQuery("SELECT c FROM Cliente c WHERE p.id : = CLIENTE_ID");
q.setParameter("CLIENTE_ID","666");
Cliente miClienteBuscado = (Cliente) q.getSingleResult();
Como se puede, estamos trabajando con “objetos” no con cláusulas SQL.
¿Y tenemos que tener esas consultas JPQL embebidas en el código?
Aquí tenemos otra ventaja de JPA, Si no queremos, no tenemos porque. Podemos si
queremos definir “anotaciones” con las sentencias SQL en el cuerpo del “Entity”, estas
sentencias SQL se indicarían con la anotación “@NamedQuery”. Un ejemplo:
Fíjate en el código del Entity, es una clase llamada “Usuario” que implementa los datos de
un usuario. Con @Entity ya indicamos que es una entidad. con @Table ya forzamos a que
se mapee con una tabla llamada “Usuarios”, en caso de no usar la anotación @Table, el
nombre de la tabla creada se llama exactamente igual al nombre de la clase java.
Con la anotación @NamedQueries vamos indicando las diferentes sentencias SQL que
queremos utilizar,en realidad sentencias JPQL. Y esto es “fantástico” otra vez, pues al ser
anotaciones, podemos cambiarlas sobre “la marcha”. Aquí aprovecho y comento otras
anotaciones de las que no había hablado, ya vimos que con @Id vamos indicando que
columnas son clave. Pues bien con @GeneratedValue podemos indicar si queremos que
los campos clave se creen de manera automática, por ejemplo mediante el uso de
secuencias. En otro caso, somos nosotros los que debemos calcular el valor de un nuevo id
cuando vayamos a insertar, o Podemos elegir Identity y que se genere una clave
autoincremental. Otra anotación es @Column nos permite asociar un atributo a un
nombre de columna en particular. Por ejemplo tenemos un atributo llamado “fCreacion”
pero en la base de datos la columna se llama “FECHA_CREACION”. En caso de no indicarlo,

las columnas de la tabla se llamaran igual que el nombre del atributo del Entity.
En el caso de que queramos usar las anotaciones @NamedQuery, si que cambia un poco la
forma de invocar a “Query” que vimos un poco mas arriba. y es que en este caso, en lugar
de usar un createQuery(“String con el JPSQL”), debemos usar
createNativeQuery(“nombre_de_la_anotacion_namedQuery_definida_en_el_Entity”).
Por ejemplo si tuviéramos:
@NamedQuery(name = "Usuario.findById", query = "SELECT u FROM Usuario" +
"u WHERE u.id = :id")
La consulta podria ser:
Query q = em.createNativeQuery("Usuario.findByID");
q.setParameteR("id","100");
Usuario u = q.getSingleResult();
En este punto también comentar que en entornos de desarrollo (Eclipse, netbeans) puede
hacerse el paso inverso, es decir, a partir de una base de datos, generar el Entity
correspondiente. A este proceso se le llama “Ingeniería inversa”. Pero no lo cubriremos en
este artículo.
Se puede de todas formas obtener más información en el sitio de Eclipse o en Netbeans.
De todas formas, pienso que lo más cómodo es escribirlo uno mismo (además el Entity es
un simple bean).
El netbeans, nos crea automáticamente las entidades, las Unidades de Persistencia, y
también nos permite crear "Controladores" para las entidades, que son clases que ya
tienen implementados los metidos del EntityManager.
Cuando vamos a crear un nuevo archivo, buscamos en la categoría "Persistencia" y ahí
encontramos lo nombrado anteriormente.

Ejemplo:
Antes se tenía que hacer una consulta en la base de datos, empleaba JDBC a o
Frameworks como iBatis e Hibernate. Eran APIs que permiten mapear una clase Java
(Bean) con una tabla de la base de datos y facilitan mucho el trabajar con la persistencia
de los objetos (usando métodos del estilo a “select”, “insert”, “update” y “delete”).
Con JPA puedes hacer cosas como estas:
- Escribir el código de tu clase, y aunque no exista la tabla correspondiente en la base de
datos, no importa. JPA se encargara de crear la tabla del modelo de datos. Es decir, tu solo
escribes el código y JPA con su mecanismo de persistencia ya se encargara de crear las
tablas, si no existen y si existen pues las usa. Además da igual la base de datos, podrías por
ejemplo escribir la aplicación en MySQL y después con un ligero cambio llevártela a Oracle.
- Sincronización. Viene tu jefe de proyecto y te dice, quiero que añadas dos columnas
nuevas a esta tabla y elimines el campo primario de esta otra tabla. Y ya empiezas a sudar.
Llevas escritas más de 20 sentencias SQL y te toca cambiarlas. Eso se acabó. Es tan sencillo
como irte al código de tu bean, y añadir 2 atributos nuevos que se mapearan como
campos nuevos de la tabla. Chachi.
- Puedes también mantener la persistencia no necesariamente atacando a una base de
datos, tal vez te interesaría persistir un objeto a un fichero de texto plano o XML.

Como ejemplo de uso de JPA vamos a implementar un pequeño sistema CMSpersonal. La
idea es escribir una pequeña aplicación que nos permita almacenar nuestros documentos
en la base de datos. Y al decir “almacenar” me refiero a almacenar el contenido del
documento en la propia base de datos, no su pathname o ruta en el disco duro. De esta
manera aprovecharemos para ver como con JPA se hace también muy simple la inserción
en campos BLOB de la base de datos, algo que muchas veces trae de cabeza a los
desarrolladores de Java.
Este ejemplo de CMS será muy simple. He preferido que el ejemplo no se complique con
restricciones o constraints de la base de datos, así que no existen tampoco claves foráneas
a otras tablas. De manera que será difícil que nos dé un error, cuando intentemos insertar
algún contenido. También en esta primera versión solo os dejare una aplicación en modo
consola (un intérprete de comandos) que nos permitirá ir insertando o consultando los
documentos de nuestra base de datos. En otro artículo posterior, veremos cómo crear un
interface gráfico vía web que nos permita manipular los documentos.
¿Qué necesitamos?
- Pues un editor de Java. Puedes usar el que más rabia te dé. Eclipse, Netbeans u otro. Yo
esta vez he usado Netbeans, para ir variando.
- Una base de datos. El ejemplo está preparado para MySQL pero funcionara con ligeros
cambios en Oracle u otra base de datos relacional. A su vez, no te olvides de incluir el
driver JDBC de conexión a la base de datos en el Classpath.
- y por último y lo más importante, para trabajar con JPA necesitamos una implementación
de JPA. Existen muchos fabricantes que han hecho la suya En el ejemplo yo he
empleado EclipseLink, así que básicamente, descárgate esta implementación,
descomprímela y copia los siguientes .jar en el classpath de tu proyecto:
- eclipselink.jar

- javax.persistence_1.0.0.jar
En Netbeans podemos por ejemplo crear una Librería con esos jar, que luego incluiremos
en el proyecto, en Eclipse, pues bastaría con añadirlos al classpath.
JPA trabaja fuertemente con anotaciones. Para mapear un bean (una clase java) con una
tabla de la base de datos, tendríamos que escribir lo que se llama un Entity.
Esto es tan sencillo como escribir nuestro Bean, con sus atributos y métodos get y set. Y
después añadirle la anotacion “@Entity” a la par que seleccionamos uno de sus atributos
como clave primaria con “@Id”. Por ejemplo, el siguiente trozo de código podría ser un
Entity, que nos permitiría luego almacenar, recuperar, o actualizar campos sobre una tabla
“usuario”:
@Entity
public class Usuario
{
@Id
private String id;
private String name;
private String email;
}
Con solo esto ya tenemos creada una “entidad” llamada “Usuario” y podríamos insertar,
actualizar o eliminar entradas en una tabla llamada “Usuario” aunque esta aún no existe,
siquiera. A que mola
Un fichero muy importante que tenemos que crear a parte de las clases “Entity” es el
fichero “persistence.xml”, en este fichero vamos a indicar precisamente que clases son
Entity, sobre qué base de datos vamos a atacar, y cuál es la política de creación de esta
base de datos.
Este fichero “persistence.xml” debe colgar de un directorio “META-INF” que este accesible
en el CLASSPATH. Esto es, si tu código por ejemplo lo estás dejando en la carpeta “src”,
tendrás que crear una carpeta “src/META-INF” y ahí dentro crear el fichero
“persistence.xml”.
El contenido de este fichero es similar al que puedes ver en la siguiente imagen:

- Tiene un nombre “DOCSPU” en el tag, este es importante, pues luego es por ese nombre
por el que podremos acceder a este recurso o unidad de persistencia. Aquí se llama
“DOCSPU” pero puedes darle el nombre o alias que quieras.
- Entremos y vamos añadiendo todas las clases Entity que queremos manipular. Esto
también es muy importante, porque si creas un Entity pero no lo añades a esta sección del
XML, para JPA no existe.
- Y por último están los properties. En estos properties estamos definiendo el mecanismo
de conexión a la base de datos. Cambiando estos valores por los adecuados podemos
conectar a cualquiera otra base de datos que tengamos.
- Existe una última propiedad que conviene tener activa en los primeros momentos,
cuando estamos desarrollando:
Esta propiedad hace que si el modelo de datos no existe se cree de manera automática,
pero cada vez que invocamos al mecanismo de persistencia, borra el contenido de las
tablas y las vuelve a crear si no existen previamente. Esto al comienzo cuando estamos de
“pruebas” viene de fábula, después ya podemos comentar esta opción para trabajar con
datos reales que tengamos insertados.
Tenemos los Entity ya creados. Como puedo por ejemplo, insertar uno de ellos en la base
de datos.
Pues con un trozo de código similar al siguiente:
- Primero creamos un EntityManager que nos permita manipular y trabajar con los objeto
Entity:
String UNIDAD_DE_PERSISTENCIA = "DOCSPU";
EntityManagerFactory factory =

Persistence.createEntityManagerFactory(UNIDAD_DE_PERSISTENCIA,
System.getProperties());
em = factory.createEntityManager();
Como ves, el nombre que uso es “DOCSPU”, esto es porque así lo tenemos definido en el
fichero “persistence.xml”, así sabe cómo recuperar las clases y propiedades que
corresponden a esta unidad de persistencia. Si tú cambiaste el nombre en el XML, aquí
deberías poner el que hayas usado.
Una vez creada la EntityManager, ya es muy simple, abrir una transacción e incluso
almacenar elementos (Entity) en la base de datos. Un ejemplo para insertar un “Usuario”
podría ser:
em.getTransaction().begin();
Usuario u = new Usuario();
u.setId(100);
u.setName("jose");
u.setEmail("notengo@gmail.com");
em.persist(u);
em.flush();
em.getTransaction().commit();
Como observas, hemos recuperado una transacción (getTransaction), instanciado un
objeto usuario, asignado valores a sus atributos, lo hemos “persistido” (almacenado) en la
base de datos con “persist” y por ultimo un commit de la transacción.
Es decir, solo escribiendo una clase, y un XML, ya hemos insertado un usuario con campos
nombre y email en una tabla “Usuarios” que se ha generado de manera dinámica. ¿No te
parece ideal?.
No hay que escribir métodos, insert, update ni delete, ni crear el modelo de la tabla si no
nos interesa. Todo se hace dinámicamente.
Consultas:
Para hacer las consultas en JPA se emplea un lenguaje denominado JPQL, no es SQL
exactamente porque trabaja con “objetos” no con “columnas” pero si muy parecido.
Por ejemplo, si la consulta de todos los campos de una tabla es “SELECT * FROM
USUARIOS”, en JPQL la consulta seria “SELECT u FROM Usuario u”, Donde “Usuario” no es
el nombre de una tabla, sino de la clase “Entity” y “u” son los identificadores del objeto.
Más ejemplos: “SELECT u.id,u.name FROM Usuario u where u.name LIKE := PARAMETRO”.
Es muy parecido a construir un PreparedStatement donde pasamos los parametros.
Para ejecutar estas consultas empleamos el objeto “Query”. Query admite dos métodos:
- getResultList, cuando el conjunto de valores devuelto es una lista de valores, por ejemplo

un SELECT de varios campos.
- getSingleResult, cuando solo se devuelve un único objeto (fila).
Por ejemplo para obtener Todos los proyectos de una tabla “Proyectos”:
Query q = em.createQuery("SELECT p FROM MdcoreProject p");
List<MdcoreProject>proyectos = q.getResultList();
intnum_proyectos = proyectos.size();
Si quisieramos ejecutar consultas con parametros, las variables a sustituir van precedidas
de “:” y debemos pasarlas con setParameter. Ejemplo: una consultas de proyecto cuyo
proyecto es “666″ seria:
Query q = em.createQuery("SELECT p FROM MdcoreProject p WHERE p.id: =
PROYECTO_ID");
q.setParameter("PROYECTO_ID","666");
MdcoreProjectmi_proyecto_buscado = (MdcoreProject)
q.getSingleResult();
Como vemos, estamos trabajando con “objetos” no con cláusulas SQL.
¿Y tenemos que tener esas consultas JPQL embebidas en el código?
Pues aquí tenemos otra ventaja de JPA, Si no queremos, no tenemos porque. Podemos si
queremos definir “anotaciones” con las sentencias SQL en el cuerpo del “Entity”, estas
sentencias SQL se indicarían con la anotacion “@NamedQuery”. Un ejemplo:

Fíjate en el código del Entity, es una clase llamada “MdcoreUser” que implementa los
datos de un usuario. Con @Entity ya indicamos que es una entidad. con @Table ya
forzamos a que se mapee con una tabla llamada “MDCORE_USER”, en caso de no usar la
anotacion @Table, el nombre de la tabla creada se llama exactamente igual al nombre de
la clase java.
Con la anotacion @NamedQueries vamos indicando las diferentes sentencias SQL que
queremos utilizar, bueno, perdón… sentencias JPQL. Y esto es “fantástico” otra vez, pues al
ser anotaciones, podemos cambiarlas sobre “la marcha”. Aquí aprovecho y comento otras
anotaciones de las que no había hablado, ya vimos que con @Id vamos indicando que
columnas son clave. Pues bien con @GeneratedValue podemos indicar si queremos que
los campos clave se creen de manera automática, por ejemplo mediante el uso de
secuencias. En otro caso, somos nosotros los que debemos calcular el valor de un nuevo id
cuando vayamos a insertar. Otra anotacion es @Column nos permite asociar un atributo a
un nombre de columna en particular. Por ejemplo tenemos un atributo llamado
“fxCreacion” pero en la base de datos la columna se llama “FECHA_CREACION”. En caso de
no indicarlo, las columnas de la tabla se llamaran igual que el nombre del atributo del
Entity.
En el caso de que queramos usar las anotaciones @NamedQuery, sí que cambia un poco la
forma de invocar a “Query” que vimos un poco más arriba. y es que en este caso, en lugar
de usar un createQuery(“String con el JPSQL”), debemos usar createNativeQuery
(“nombre_de_la_anotacion_namedQuery_definida_en_el_Entity”).
Porejemplosituvieramos:

@NamedQuery(name = "MdcoreUser.findById", query = "SELECT s FROM
MdcoreUser" +
"s WHERE s.id = :id")
La consulta podría ser:
Query q = em.createNativeQuery("MdcoreUser.findByID");
q.setParameteR("id","100");
MdcoreUser u = q.getSingleResult();
En este punto también comentar que en estos entornos de desarrollo (Eclipse, netbeans)
puede hacerse el paso inverso, es decir, a partir de una base de datos, generar el Entity
correspondiente. A este proceso se le llama “Ingeniería inversa”.

Recomendaciones
 El uso de JPA se recomienda ya que simplifica la programación de la lógica de
persistencia y en un dominio orientado completamente a objetos se tiene
información que reduce hasta un 40% el código.
 Se debe tener buen conocimiento de la tecnología a la hora de configurar JPA, ya
que de esto dependerá el rendimiento de las aplicaciones.
 Es importante conocer los parámetros de tunning incluidos en la implementación
del JPA.
 Es importante configurar la cache, ya que es un parámetro importante para el
tunning.
 Ajustar el pool de conexiones es importante para lograr el mejor rendimiento.
 Parámetros como statemet cache se deben configurar explícitamente para algunas
bases de datos de Oracle.
 La configuración de la virtual machine juega un papel en el manejo de la
persistencia.

Conclusiones
 El proyecto busca no perder las ventajas de la orientación a objetos al interactuar
con bases de datos.
 Proporciona persistencia no solo a base de datos sino también a: Objetos, ficheros
planos y XML entre otros.
 El grupo de trabajo Enterprise java beans decidió estandarizar en Java persistence
API las demás API de persistencia de datos.
 El uso de recursos al acceder a datos se ve incrementado.
 No implementa el uso de procedimientos almacenados.
 Se reemplaza el uso del SQL por JPQL ya que JPA trabaja con objetos y no con
columnas.
 En entornos Eclipse y NetBeans se puede lograr ingeniería inversa, obteniendo de
una base de datos el entity (esquema de anotaciones para mapear una base de
datos) correspondiente.

Egrafias
http://es.wikipedia.org/wiki/Java_Persistence_API
http://www.aprendiendojava.com.ar/index.php?topic=54.0
http://www.slideshare.net/hernanvid/jpa-10294017
http://www.slideshare.net/maxmouse/java-persistence-api-jpa
http://www.slideshare.net/dpecos/t3-jpa
http://www.slideshare.net/hernanvid/jpa-10294017

Java persitence api

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Destaque

Destaque (10)

Semelhante a Java persitence api

Semelhante a Java persitence api (20)

Java persitence api