Las relaciones Mucho a Muchos (@ManyToMany) se caracterízan por Entidades que están relacionadas con a muchos elementos de un tipo determinado, pero al mismo tiempo, estos últimos registros no son exclusivos de un registro en particular, si no que pueden ser parte de varios, por lo tanto, tenemos una Entidad A, la cual puede estar relacionada como muchos registros de la Entidad B, pero al mismo tiempo, la Entidad B puede pertenecer a varias instancias de la Entidad A.

Algo muy importante a tomar en cuenta cuando trabajamos con relaciones @ManyToMany, es que en realidad este tipo de relaciones no existen físicamente en la base de datos, y en su lugar, es necesario crear una tabla intermedia que relaciones las dos Entidades, veremos más adelante como resolvemos eso.

Un ejemplo clásico de estas relaciones son los libros con sus autores, de esta forma, un libro puede tener varios autores, y a su vez, los autores puede tener muchos libros. Pero para que quede más claro, veamos como quedarían las Entidades de Autor (Author), Libro (Book):

Entidad Book:

package com.oscarblancarteblog;

import java.util.ArrayList;
import java.util.List;
import javax.persistence.*;

@Entity
@Table(name = "books")
public class Book {
    @Id
    @Column(name="ID")
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;
    
    @Column(name = "NAME", nullable = false)
    private String name;
    
    @JoinTable(
        name = "rel_books_auths",
        joinColumns = @JoinColumn(name = "FK_BOOK", nullable = false),
        inverseJoinColumns = @JoinColumn(name="FK_AUTHOR", nullable = false)
    )
    @ManyToMany(cascade = CascadeType.ALL)
    private List<Author> authors;
   
    public void addAuthor(Author author){
        if(this.authors == null){
            this.authors = new ArrayList<>();
        }
        
        this.authors.add(author);
    }

    /** GET and SET */
  
}

Como podemos apreciar, hemos creado una lista de tipo Author, la cual es anotada con @ManyToMany, adicional, hemos definido la anotación @JoinTable, la cual nos sirve para definir la estructura de la tabla intermedia que contendrá la relación entre los libros y los autores.

La anotación @JoinTable no es obligatoria en sí, ya que en caso de no definirse JPA asumirá el nombre de la tabla, columnas, longitud, etc. Para no quedar a merced de la implementación de JPA, siempre es recomendable definirla, así, tenemos el control total sobre ella.

Hemos definidos las siguientes propiedades de la anotación @JoinTable:

• name: Nombre de la tabla que será creada físicamente en la base de datos.
• joinColumns: Corresponde al nombre para el ID de la Entidad Book.
• inverseJoinColumns: Corresponde al nombre para el ID de la Entidad Author

Entidad Author:

package com.oscarblancarteblog;

import java.util.ArrayList;
import java.util.List;
import javax.persistence.*;

@Entity
@Table(name="authors")
public class Author {
    
    @Id
    @Column(name="ID")
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;
    
    @Column(name="NAME", nullable = false)
    private String name;
    
    @ManyToMany(mappedBy = "authors")
    private List<Book> books;

    /** GET and SET **/
}

El caso de la Entidad Author es más simple, pues solo marcamos la colección con @ManyToMany, pero en este caso ya no es necesario definir la anotación @JoinTable, en su lugar, definimos la propiedad mappedBy para indicar la relación bidireccional y al mismo tiempo, JPA puede tomar la configuración del @JoinTable de Books.

Como resultado de estas Entidades, tendremos las siguientes tablas auto generadas:

Notemos en la tabla authors no tiene una columna que haga referencia a books, ni books a authors, si no que es necesario tener una tabla intermedia que haga el cruce entre las dos tablas.

La tabla intermedia (rel_book_auths) es generada por la anotación @JoinTable y sus dos columnas son llaves foraneas a las tablas books y authors.

Prueba de validación

Para comprobar que todo funciona como lo hemos dicho, vamos a realizar una prueba, la cual se ve de la siguiente manera:

public static void main(String[] args) {
        
	//Authors
	Author author1 = new Author();
	author1.setName("Juan Perez");
	
	Author author2 = new Author();
	author2.setName("Oscar Blancarte");
	
	Author author3 = new Author();
	author3.setName("Arturo Martinez");
	
	
	//Books
	Book book1 = new Book();
	book1.setName("El lago y el pato");
	book1.addAuthor(author1);
	book1.addAuthor(author2);
	book1.addAuthor(author3);
	
	Book book2 = new Book();
	book2.setName("Una mañana de verano");
	book2.addAuthor(author1);
	book2.addAuthor(author2);
	book2.addAuthor(author3);
	
	EntityManager em = EntityManagerUtil.getEntityManager();
	em.getTransaction().begin();
	em.persist(book1);
	em.persist(book2);
	em.getTransaction().commit();
	
	System.out.println("FIN");
}

Hemos creados dos libros y tres autores, y luego hemos asociado a los autores a los libros, con la intención de que los autores estén en dos libros y los libros tengan varios autores.

Tambíen los quiero invitar a ver mi curso de JPA, donde explico todos estos temas aplicados con API REST, https://codmind.com/courses/jpa

Ahora veamos como se ven las tablas authors, books y rel_books_auths:

Para poder obtener la relación entre libros y autores solo faltaría hacer la unión entre las dos tablas.

Conclusiones

Para concluir solo faltaría resaltar que en las relaciones @ManyToMany los registros son independientes de los registros a los que son relacionados, por lo que en este caso, podrían existir los autores si no existieran los libros, y al revés.

Las relaciones uno a muchos (@OneToMany) se caracterizan por Entidad donde tenemos un objeto principal y colección de objetos de otra Entidad relacionados directamente. Estas relaciones se definen mediante colecciones, pues tendremos una serie de objetos pertenecientes al objeto principal.

Este articulo es parte de un guia completa de JPA, para ver el contenido completo puedes ir a Java Persistence API (JPA)

Un ejemplo clásico para entender este tipo de relaciones son las facturas, pues tendremos una Entidad cabecera donde tengamos los datos principales de la factura, como podría ser serie, cliente, total, fecha de expedición, etc. Por otra parte, la factura tendrá una serie de líneas que representa cada uno de los productos vendidos. 

Veamos como quedaría la entidad Invoice (factura):

package com.obb.jpa.jpaturorial.entity;

import java.util.Calendar;
import java.util.List;
import javax.persistence.*;

@Entity
@Table(name="INVOICES")
public class Invoice {
    
    @Id
    @Column(name="ID")
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private long id;
    
    @Column(name = "STATUS", length = 20, nullable = false)
    @Enumerated(EnumType.STRING)
    private Status status;
    
    @Temporal(TemporalType.TIMESTAMP)
    @Column(name = "REGIST_DATE", nullable = false)
    private Calendar registDate;
    
    @JoinColumn(name = "FK_CUSTOMER", nullable = false)
    @ManyToOne(optional = false, cascade = CascadeType.ALL, fetch = FetchType.EAGER)
    private Customer customer;
    
    @OneToOne(mappedBy = "invoice", cascade = CascadeType.ALL)
    private Payment payment;
    
    @OneToMany(cascade = CascadeType.ALL, mappedBy = "invoice")
    private List<InvoiceLine> lines;

    /** GET and SET */
}

Podemos apreciar como hemos definido la propiedad lines como una lista (List), lo cual nos permite relacionar la factura con un número indeterminado de líneas, por otro lado, hemos definido la propiedad mappedBy para indicar que es una relación bidireccional, es decir, la Entidad InvoiceLine tendrá también una relación hacia la Entidad Invoice.

La Entidad InvoiceLine se verá de la siguiente manera:

package com.obb.jpa.jpaturorial.entity;

import javax.persistence.*;

@Entity
@Table(name = "invoice_lines")
public class InvoiceLine {
    @Id
    @Column(name = "ID")
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;
    
    @Column(name = "PRODUCT", nullable = false)
    private String product;
    
    @Column(name = "PRICE", nullable = false)
    private double price;
    
    @Column(name = "TOTAL", nullable = false)
    private double quantity;
    
    @ManyToOne
    @JoinColumn(name = "FK_INVOICE", nullable = false, updatable = false)
    private Invoice invoice;
    
    /** GET and SET */

}

Como dijimos hace un momento, la Entidad InvoiceLine tiene una propiedad de tipo Invoice para poderla hacer bidireccional, observemos que el nombre de la propiedad invoice corresponde con el valor del mappedBy definido en la Entidad Invoice, ya que de lo contrario JPA nos arrojará un error.

Tambíen los quiero invitar a ver mi curso de JPA, donde explico todos estos temas aplicados con API REST, https://codmind.com/courses/jpa

En este imagen podemos apreciar que la tabla invoice_lines tiene la columna FK_INVOICE que será utilizada para realizar el JOIN con la tabla invoices, de tal forma que cada registro de invoice_lines que sea encontrado será convertido en una instancia de la Entidad InvoiceLine.

public static void main(String[] args) {
    Invoice invoice = new Invoice();

    List<InvoiceLine> lines = new ArrayList<>();
    for(int c = 0; c<10; c++){
        InvoiceLine line = new InvoiceLine();
        line.setInvoice(invoice);
        line.setPrice(10);
        line.setProduct("Product " + (c+1));
        line.setQuantity(c+1);
        lines.add(line);
    }

    Customer customer = new Customer();
    customer.setName("Oscar Blancarte");

    invoice.setCustomer(customer);
    invoice.setLines(lines);
    invoice.setRegistDate(Calendar.getInstance());
    invoice.setStatus(Status.ACTIVE);

    EntityManager em = EntityManagerUtil.getEntityManager();
    em.getTransaction().begin();
    em.persist(invoice);
    em.getTransaction().commit();
}

Dando como resultado los siguientes registros en la base de datos:

Ahora si podemos ver todo materializado y nos queda más la forma en que la información es almacenada. 

Conclusiones

Hemos comprobado lo simple que es crear relaciones @OneToMany y hemos podido comprobar como  la información es almacenada, solo faltaría resaltar que JPA no garantiza el orden en que los elementos de la colección son insertados, es por ello, que siempre se aconseja tener una columna que indique el orden natural de los elementos para sobre esa columna hacer el ordenamiento, esto claro si nos interesa mantener el ordenamiento, en caso podemos ignorarlo.

Nota: Este artículo pertenece a un tutorial completo de JPA, el cual puedes ver aquí.

La anotación @JoinColumn  se puede llegar a confundir con @Column , sin embargo, tiene una funcionalidad diferente, @JoinColumn  se utiliza para marcar una propiedad la cual requiere de un JOIN para poder accederlas, mientas que @Column  se utiliza para representar columnas simples que no están relacionadas con otra Entidad. A pesar de que se utiliza para cosas distintas, la realidad es que se parecen muchísimo, pues tiene casi las mismas propiedades, por que podríamos decir que @JoinColumn  es el equivalente de @Column  cuando utilizamos relaciones con Entidades.

En la entrada pasada de este tutorial explicamos el caso de la Entidad Factura (Invoice ) y Cliente (Customer ), donde dijimos que toda factura está relacionada a un cliente, y utilizamos la anotación @ManyToOne  para crear la relación, recordemos como quedaron estas Entidades:

package com.obb.jpa.jpaturorial.entity;
 
import java.util.Calendar;
import javax.persistence.CascadeType;
import javax.persistence.Column;
import javax.persistence.Entity;
import javax.persistence.EnumType;
import javax.persistence.Enumerated;
import javax.persistence.FetchType;
import javax.persistence.GeneratedValue;
import javax.persistence.GenerationType;
import javax.persistence.Id;
import javax.persistence.ManyToOne;
import javax.persistence.Table;
import javax.persistence.Temporal;
import javax.persistence.TemporalType;
 
@Entity
@Table(name="INVOICES")
public class Invoice {
    
    @Id
    @Column(name="ID")
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private long id;
    
    @Column(name = "STATUS", length = 20, nullable = false)
    @Enumerated(EnumType.STRING)
    private Status status;
    
    @Temporal(TemporalType.TIMESTAMP)
    @Column(name = "REGIST_DATE", nullable = false)
    private Calendar registDate;
    
    @ManyToOne(optional = false, cascade = CascadeType.ALL, fetch = FetchType.EAGER)
    private Customer customer;
 
    /** GET and SET */
}

Entidad Customer:

package com.obb.jpa.jpaturorial.entity;
 
import javax.persistence.Column;
import javax.persistence.Entity;
import javax.persistence.GeneratedValue;
import javax.persistence.GenerationType;
import javax.persistence.Id;
import javax.persistence.Table;
 
@Entity
@Table(name = "CUSTOMERS")
public class Customer {
    
    @Id
    @Column(name = "ID")
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private long id;
    
    @Column(name = "NAME", nullable = false, length = 100)
    private String name;
 
    /** GET and SET */
}

Podemos ver claramente que la Entidad Invoice  tiene una relación @ManyToOne  con la Entidad Customer , esto le indica a JPA que requerirá hacer un JOIN para poder recuperar al Cliente, sin embargo, no hemos definido la anotación @JoinColumn  y aun así trabaja, ¿cómo es esto posible?

Para comprender esto mejor, será necesario ver como JPA auto creo las tablas al momento de crear el schema, veamos las tablas generadas:

Podemos ver claramente que JPA creo la columna CUSTOMER_ID en la tabla invoices, pero no solo eso, si no que además, creo por nosotros la llave foránea, esto nos puede hacer pensar que la anotación @JoinColumn  no es necesaria, y pueda que tengas razón, sin embargo, no utilizarla nos dejará a merced de como JPA genere la columna y como realice el JOIN con la tabla de empleados, lo cual será un verdadero problema si el Schema ya existe, pues muy probablemente la consulta falle al buscar la columna con un nombre diferente del que JPA asumiría.

Ahora bien, con @JoinColumn , podría definir el nombre exacto de la columna, si admite nulos, si es actualizable, insertable, indicar si queremos que genere o no la llave foránea o incluso, podríamos decirle sobre que Tabla debe generar el Join. Mejor veamos como quedaría la Entidad Invoice  utilizando la anotación @JoinColumn :

package com.obb.jpa.jpaturorial.entity;
 
import java.util.Calendar;
import javax.persistence.CascadeType;
import javax.persistence.Column;
import javax.persistence.Entity;
import javax.persistence.EnumType;
import javax.persistence.Enumerated;
import javax.persistence.FetchType;
import javax.persistence.GeneratedValue;
import javax.persistence.GenerationType;
import javax.persistence.Id;
import javax.persistence.ManyToOne;
import javax.persistence.Table;
import javax.persistence.Temporal;
import javax.persistence.TemporalType;
 
@Entity
@Table(name="INVOICES")
public class Invoice {
    
    @Id
    @Column(name="ID")
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private long id;
    
    @Column(name = "STATUS", length = 20, nullable = false)
    @Enumerated(EnumType.STRING)
    private Status status;
    
    @Temporal(TemporalType.TIMESTAMP)
    @Column(name = "REGIST_DATE", nullable = false)
    private Calendar registDate;
    
    @JoinColumn(name = "fk_customer", nullable = false)
    @ManyToOne(optional = false, cascade = CascadeType.ALL, fetch = FetchType.EAGER)
    private Customer customer;
 
    /** GET and SET */
}

Ahora veamos como quedaría la nueva tabla invoices:

En esta segunda tabla ya vemos que ha cambiado el nombre de la columna, adicional se ha creado el constraint para no permitir valores nulos, aun que esto último no se pueda ver en la imagen.

Propiedades de @JoinColumn

Ahora pasemos a analizar las propiedades que nos brinda @JoinColumn :

• name: Indica el nombre con el que se deberá de crear la columna dentro de la tabla.
• referencedColumnName: Se utiliza para indicar sobre que columna se realizará el Join de la otra tabla. Por lo general no se suele utilizar, pues JPA asume que la columna es el ID de la Entidad objetivo.
• unique: Crea un constraints en la tabla para impedir valores duplicados (default false).
• nullable: Crea un constraints en la tabla para impedir valores nulos (default true).
• insertable: Le indica a JPA si este valor deberá guardarse en la operación de inserción (default true)
• updatable: Le indica a JPA si el valor deberá actualizarse durante el proceso de actualización (default true)
• columnDefinition: Esta propiedad es utiliza para indicar la instrucción SQL que se deberá utilizar la crear la columna en la base de datos. Esta nos ayuda a definir exactamente como se creará la columna sin depender de la configuración de JPA.
• table: Le indicamos sobre que tabla deberá realizar el JOIN, normalmente no es utilizada, pues JPA asume la tabla por medio de la entidad objetivo.
• foreignKey: Le indica a JPA si debe de crear el Foreign Key, esta propiedad recibe uno de los siguientes valores CONSTRAINT , NO_CONSTRAINT , PROVIDER_DEFAULT  definidos en la enumeración javax.persistence.ForeignKey .

Tambíen los quiero invitar a ver mi curso de JPA, donde explico todos estos temas aplicados con API REST, https://codmind.com/courses/jpa

Conclusiones

Hemos podido analizar como es que JPA se apoya de @JoinColumn  para permitirle al programador personalizar cada aspecto de la columna de unión, lo cual es bastante bueno para poder respetar los estándares o nomenclaturas que usamos en nuestra empresa o proyecto. Como recomendación, yo siempre insisto en definir estas anotaciones, pues no es conveniente quedarnos a merced de la implementación de JPA para que defina como crear nuestras columnas.

Para comprender esto, analicemos el ejemplo de las facturas, estas siempre son emitidas a un cliente, por lo que el objeto Factura siempre deberá tener una propiedad que represente al cliente. Normalmente, esta propiedad seria el ID, sin embargo, JPA nos permite tener una referencia a la Entidad cliente. Veamos cómo quedaría la Entidad Invoice  (factura)

package com.obb.jpa.jpaturorial.entity;

import java.util.Calendar;
import javax.persistence.CascadeType;
import javax.persistence.Column;
import javax.persistence.Entity;
import javax.persistence.EnumType;
import javax.persistence.Enumerated;
import javax.persistence.FetchType;
import javax.persistence.GeneratedValue;
import javax.persistence.GenerationType;
import javax.persistence.Id;
import javax.persistence.ManyToOne;
import javax.persistence.Table;
import javax.persistence.Temporal;
import javax.persistence.TemporalType;

@Entity
@Table(name="INVOICES")
public class Invoice {
    
    @Id
    @Column(name="ID")
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private long id;
    
    @Column(name = "STATUS", length = 20, nullable = false)
    @Enumerated(EnumType.STRING)
    private Status status;
    
    @Temporal(TemporalType.TIMESTAMP)
    @Column(name = "REGIST_DATE", nullable = false)
    private Calendar registDate;
    
    @ManyToOne(optional = false, cascade = CascadeType.ALL, fetch = FetchType.EAGER)
    private Customer customer;

    /** GET and SET */
}

Como podemos apreciar, hemos utiliza la anotación @ManyToOne , la cual nos permite mapear una entidad con otra. Como única regla, es necesario la clase que sea una entidad, es decir, que también esté anotada con @Entity .

Por otro lado, tenemos la entidad Customer , la cual se ve de la siguiente manera:

package com.obb.jpa.jpaturorial.entity;

import javax.persistence.Column;
import javax.persistence.Entity;
import javax.persistence.GeneratedValue;
import javax.persistence.GenerationType;
import javax.persistence.Id;
import javax.persistence.Table;

@Entity
@Table(name = "CUSTOMERS")
public class Customer {
    
    @Id
    @Column(name = "ID")
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private long id;
    
    @Column(name = "NAME", nullable = false, length = 100)
    private String name;

    /** GET and SET */
}

Estas dos entidades nos crearán las siguientes tablas:

La anotación @ManyToOne cuenta con los siguientes atributos:

• Optional: indica si la relación es opcional, es decir, si el objeto puede ser null. Esta propiedad se utiliza optimizar las consultas. Si JPA sabe que una relación es opcional, entonces puede realizar un RIGHT JOIN  o realizar la consulta por separado, mientras que, si no es opcional, puede realizar un INNER JOIN  para realizar una solo consulta.
• Cascade: Esta propiedad le indica que operaciones en cascada puede realizar con la Entidad relacionada, los valores posibles son ALL , PERSIST , MERGE , REMOVE , REFRESH , DETACH y están definidos en la enumeración javax.persistence.CascadeType .
• Fetch: Esta propiedad se utiliza para determinar cómo debe ser cargada la entidad, los valores están definidos en la enumeración javax.persistence.FetchType  y los valores posibles son:
  • EAGER (ansioso): Indica que la relación debe de ser cargada al momento de cargar la entidad.
  • LAZY (perezoso): Indica que la relación solo se cargará cuando la propiedad sea leída por primera vez.
• targetEntity: Esta propiedad recibe una clase (Class ) la cual corresponde a la clase de la relación. No suele ser utilizada, pues JPA puede inferir la clase por el tipo de la propiedad.

En nuestro caso, hemos definido la propiedad optional en false, pues toda factura debe de tener forzosamente un Cliente (customer). La propiedad cascade la definimos en ALL  para facilitarnos la explicación de este ejemplo, pero más adelante en este tutorial analizaremos las cascadas en profundidad. La propiedad fetch la definimos en EAGER , aun que para este tipo de relación es su valor por default y no sería necesario definirlo.

Ejemplo práctico

Crearemos un pequeño ejemplo que nos permita comprobar cómo trabajar con esta relación, para ello, crearemos una nueva factura con un cliente:

public static void main(String[] args) {
    EntityManager manager = EntityManagerUtil.getEntityManager();
        
    Customer customer = new Customer();
    customer.setName("ACME Corp");
      
    Invoice invoice = new Invoice();
    invoice.setCustomer(customer);
    invoice.setRegistDate(Calendar.getInstance());
    invoice.setStatus(Status.ACTIVE);
        
    manager.getTransaction().begin();
    manager.persist(invoice);
    manager.getTransaction().commit();
}

Como resultado, podemos observar como han sido insertados la Factura y el Cliente:

Por otra parte, si consultamos la Entidad Invoice, JPA se encargará de cargar al Empleado, vamos el siguiente ejemplo:

public static void main(String[] args) {
    EntityManager manager = EntityManagerUtil.getEntityManager();
    Invoice invoice = manager.find(Invoice.class, 1L);
        
    System.out.println("Invoice ID > " + invoice.getId());
    System.out.println("Customer ID > " + invoice.getCustomer().getId());
    System.out.println("Customer Name > " + invoice.getCustomer().getName());
}

Como podemos apreciar en la siguiente imagen, no fue necesario ir a consultar el Cliente por separado, si no que JPA se encarga de recuperarlo justo en el momento en que lo necesitamos.

Finalmente, podemos ver en las siguiente imágenes como es que nos auto genero la tabla de las facturas, en ella podemos apreciar el campo CUSTOMER_ID , el cual es en realidad una llave foránea a la tabla de clientes:

JPA también nos ayuda a crear los Foreign Keys con la tabla de Clientes:

Tambíen los quiero invitar a ver mi curso de JPA, donde explico todos estos temas aplicados con API REST, https://codmind.com/courses/jpa

Conclusiones

Hemos podido observar como JPA se encarga de todo lo relacionado a persistir o recuperar el cliente de la base de datos, sin embargo, hay algo que no hemos cubierto, y es la forma en que podemos personalizar la columna, es decir, como podemos indicarle el nombre, si admite nulos o no, etc. Todas esta propiedades las podremos definir en la anotación @JoinColumn  que analizaremos en la siguiente parte del tutorial

En la sección pasada de este tutorial dimos una breve Introducción a Java Transaction API (JTA), otra forma de administrar las transacciones de forma automática por medio del Application Server. Resource Local es utilizado casi por completo en aplicaciones de escritorio o aplicaciones Core que corren de forma standalone y que por lo tanto no corren sobre toda la infraestructura que provee un Application Server forma. Las aplicaciones que decidan utilizar este tipo de transacciones deberá indicarlo al momento de crear el Persistence Unit del archivo persistence.xml:

<persistence-unit name=”JPA_PU” transaction-type=”RESOURCE_LOCAL”>

Otra de las cuestiones importantes a remarcar es que la inyección de dependencias (CDI) no estará disponible en ambientes Java SE, por lo que estaremos obligados a crear manualmente el EntityManager  a través de EntityManagerFactory, para esto podemos crearlo de la siguiente manera:

EntityManagerFactory factory = Persistence.createEntityManagerFactory(“JPA_PU”);

EntityManager manager = factory.createEntityManager();

Lo primero que se debe de crear es el EntityManagerFactory, el cual se crea a partir de la clase Persistence y se le envía como parámetro el nombre del PersistenceUnit. Seguido, es creado el EntityManager a partir del EntityManagerFactory.

 Trabajar con Transacciones Resource Local

Para trabajar con Resource Local es necesario familiarizarnos con la clase EntityTransaction:

package javax.persistence;

public interface EntityTransaction {
     public void begin();
     public void commit();
     public void rollback();
     public void setRollbackOnly();
     public boolean getRollbackOnly();
     public boolean isActive();
}

Mediante esta clase es posible controlar las transacciones de JPA, es obtenida a través del EntityManager con el método getTransaction. Esta clase una serie de métodos que nos permitirán controlar las transacciones. Los métodos son los siguientes:

• Begin: Se utiliza para iniciar una nueva transacción. Lanza una IllegalStateException cuando la transacción ya está activa.
• Commit: Realiza commit a la transacción activa. Lanza IllegalStateException cuando la transacción no está activa o RollbackException cuando se genera un error al realizar el commit
• Rollback: Realiza un Rollback de la transacción y echa atrás todos los cambios realizados durante la transacción. Lanza IllegalStateException cuando la transacción no está activa o PersistenceException ante cualquier posible error inesperado.
• setRollbackOnly: Marca la transacción para que se realice un Rollback después de terminar la ejecución (Se aconseja usar solo en EJB).
• GetRollbackOnly: Indica si la transacción ha sido marcada para hacer Rollback
• isActive: Retorna true si existe una transacción activa, false de lo contrario.

El siguiente ejemplo ilustra cómo es que suele utilizar la clase EntityTransaction:

public void saveEmployee(Employee emp){
    EntityManagerFactory factory = Persistence.createEntityManagerFactory("JPA_PU");
    EntityManager manager = factory.createEntityManager();
    try {
        manager.getTransaction().begin();
        manager.persist(emp);
        manager.getTransaction().commit();
    } catch (Exception e) {
        if(manager.getTransaction().isActive()){
            manager.getTransaction().rollback();
        }
    }
}

Este es un simple método que guarda un nuevo empleado. Primero que nada, se crear el EntityManager como ya lo explicamos, luego en la línea 5 se abre una nueva transacción, para después realizar el guardado, en la línea 7 se realiza el commit. En caso de que algo salga mal, entonces el error cae en el Catch y se valida que exista una transacción activa (línea 9) para después proceder con el Rollbak (línea 10).

Como vemos, trabajar con Resource Local puede llegar a ser un poco más complicado, pero esa es la única alternativa si estamos trabajando con aplicaciones de Escritorio.

Primero que nada, tenemos que saber que el Persistence Context se crea mediante un Persistence Unit y el Entity Manager se crea a partir de un Persistence Context, veamos la siguiente imagen para entender mejor:

Veamos que todo parte del archivo persistence.xml del cual ya hablamos anteriormente, en este archivo se definen los Persistence Unit, y mediante estos es creado el Persistence Context, el Persistence Context tiene la finalidad de delimitar el alcance de las transacciones, pero también está delimitado a administrar las Entidades definidas por el Persistence Unit con el que fue creado.  Adicionalmente, el Entity Manager hace referencia a un Persistence Context el cual será utilizado para administrar las entidades y las transacciones.

Una de las ventajas de tener varios Persistence Unit, es que nos permite definir diferentes configuraciones para cada uno, de esta manera podemos delimitar las entidades de cada módulo e incluso una configuración de base de datos diferentes para cada uno.

Container-Managed Entity Manager

Básicamente existen dos formas de trabajar con JPA, la más simple es cuando lo utilizamos en aplicaciones SE o de escritorio y la segunda forma que es la que estudiaremos en esta sección, es cuando lo utilizamos en ambientes de Java EE con EJB.

La principal característica de utilizar Entity Manager administrado por el contenedor, es que es el mismo Container el que se encarga de abrir y cerrar las transacciones, por lo que el programador solo se preocupa por implementar la lógica de negocio despreocupándose en la totalidad de las transacciones.

En ambientes Java EE se suele utilizar la anotación @PersistenceContext  para crear el EntityManager, como veremos en el siguiente EJB.

package com.obb.jpa.jpaturorial.entitymanager;

import javax.ejb.*;
import javax.persistence.*;

/**
 * @author Oscar Blancarte
 */
@EJB
@Stateless
public class EmployeeDAO implements IEmployeeDAO{

    @PersistenceContext(unitName = "JPA_PU")
    private EntityManager manager;
}

Cuando utilizamos la anotación @PersistenceContext  el contenedor inyecta de forma automática una referencia válida del EntityManager creado a partir de la Persistence Unit JPA_PU, de esta forma, el programador podrá utilizar el EntityManager en cualquier método que defina, y las transacciones será administradas de forma automática.

Ahora bien, existen dos variantes de los Container-Managed, Transaction-Scope y Extended, los cuales son utilizados en circunstancias diferentes. Para utilizar una variante o la otra, es necesario definirlo en la anotación @PersistenceContext  mediante la propiedad type. Los valores posibles son TRANSACTION  y EXTENDED  como veremos a continuación:

@PersistenceContext(unitName = "JPA_PU", type = PersistenceContextType.TRANSACTION)
@PersistenceContext(unitName = "JPA_PU", type = PersistenceContextType.EXTENDED)

En caso de no definir la propiedad type, el valor por default será TRANSACTION, lo cual está bien, porque es por lejos la variante más utilizada.

Transaction-Scope

La variante Transaction-Scope es la variante utiliza por default, por lo que no es necesario definir la propiedad type para utilizarla. Esta variante tiene la particularidad de que el contexto de persistencia solo será válido durante le ejecución de la operación de negocio, una vez que la operación termine el contexto de persistencia se destruye y todas las entidades relacionadas con el Entity Manager será descartadas.

Este tipo de estrategias se utiliza para EJB sin estado como los @Stateless, pues cada invocación a una operación de negocio se espera que realice una acción, persista y retorne un resultado, y cada ejecución tendrá un contexto de persistencia diferente, garantizando de esta forma que el servicio siempre arroje el mismo resultado para la misma entrada.

Veamos un ejemplo de un servicio de creación de empleados:

package com.obb.jpa.jpaturorial.entitymanager;
import com.obb.jpa.jpaturorial.entity.Employee; 
import javax.ejb.*; 
import javax.persistence.*; 
/** 
* @author Oscar Blancarte 
*/ 
@EJB 
@Stateless 
public class EmployeeDAO implements IEmployeeDAO{ 
@PersistenceContext(unitName = "JPA_PU", type = PersistenceContextType.TRANSACTION) 
private EntityManager manager; 

@TransactionAttribute(TransactionAttributeType.NEVER) 
public Employee getEmployeeById(Long empId){ 
//Se consulta el empleado mediante el ID 
return manager.find(Employee.class, empId); 
} 

@TransactionAttribute(TransactionAttributeType.SUPPORTS) 
public void updateEmployeeName(Long empId, String newName){ 
//El empleado es nuevamente consultado de la base de datos 
//debido a que cada invocación es un nuevo contexto de persistencia 
Employee emp = manager.find(Employee.class, empId); 
emp.setName(newName); 
//Al termina el método, el contenedor realiza un Commit automático. 
} 
}

Imaginemos el siguiente escenario, tenemos una aplicación que carga el empleado en pantalla utilizando el método getEmployeeById, esta consulta al empleado mediante el ID y lo retorna, la aplicación utiliza el empleado consultado para mostrarlo en pantalla, luego, modificamos el nombre del empleado y guardamos los cambios mediante el método updateEmployeeName.

Lo primero que hace la aplicación es consultar el empleado, hasta aquí todo bien, pero cuando actualizamos el nombre del empleado, vemos que realizamos un find mediante el ID del empleado, podríamos pensar que como ya lo hemos consultado anteriormente mediante el método getEmployeeById este solo lo retomará del cache sin realizar una nueva consulta a la base de datos, sin embargo, Transaction-Scope garantiza que cada ejecución crea un nuevo PersistenceContext en blanco, por lo que el empleado que anteriormente ya habíamos consultado será nuevamente consultado, debido que en la segunda llamada al método updateemployeeName el Persistence Context está en blanco.

No te preocupes por las anotaciones @TransactionAttribute, más adelante las explicaremos por ahora pasémoslas por alto.

Extended

La segunda variante es Extended, que como su nombre nos lo indica, se trata de un Contexto de Persistencia Extendido, donde el contexto persistirá durante todo el tiempo de vida de la sesión, sin importar el número de operaciones o transacciones que se realicen.

A diferencia de Transaction-Scope, en esta variante todos los cambios realizados en el Persistence Context seguirán vigentes, por lo que cada ejecución que realicemos se favorecerá de las ejecuciones pasadas.

Este tipo de variante es utilizada cuando trabajamos con EJB con sesión como el @Stateful, veamos el mismo ejemplo anterior pero esta vez utilizando un EJB con sesión y la variante Extended.

package com.obb.jpa.jpaturorial.entitymanager;

import com.obb.jpa.jpaturorial.entity.Employee;
import javax.ejb.*;
import javax.persistence.*;

/**
 * @author Oscar Blancarte
 */
@EJB
@Stateful
public class EmployeeExtendedDAO implements IEmployeeDAO{
    
    @PersistenceContext(unitName = "JPA_PU", type = PersistenceContextType.EXTENDED)
    private EntityManager manager;
    
    @TransactionAttribute(TransactionAttributeType.NEVER)
    public Employee getEmployeeById(Long empId){
        //Se consulta el empleado mediante el ID
        return manager.find(Employee.class, empId);
    }
    
    @TransactionAttribute(TransactionAttributeType.SUPPORTS)
    public void updateEmployeeName(Long empId, String newName){
        //El empleado no es consultado, debido a que ya fue consultado previamente
        Employee emp = manager.find(Employee.class, empId);
        emp.setName(newName);
        //Al termina el método, el contenedor realiza un Commit automático.
        //Los camibios realizados seguiran estando disponibles
    }
}

En este caso las cosas son un poco diferentes. Primero que nada, se realiza la consulta del empleado mediante el método getEmployeeById y el empleado es retornado, cuando la ejecución del método termina, el Persistence Context continúa existiendo, por lo que cuando se realiza la actualización del nombre del empleado y se realiza la consulta del empleado, el Entity Manager ya no consulta al empleado, pues este ya fue consultado en el método anterior. Finalmente, el nombre es actualizado y al terminar el método se hace un commit de la transacción. Al finalizar el método el Contexto de persistencia continua activo hasta que la sesión finaliza.

Application-Managed Entity Manager

La segunda forma de trabajar con JPA es delegar al programador la responsabilidad de administrar las transacciones, este escenario se da con mucha más frecuencia en aplicaciones de escritorio, aunque existen escenarios donde es utilizado en entornos de Java EE.

Básicamente el programador tiene que crear el EntityManager a través del EntityManagerFactory y tiene que abrir y cerrar las transacciones cada vez que requiera.

Veamos cómo quedaría el escenario anteriormente planteado utilizando application-managed:

package com.obb.jpa.jpaturorial.entitymanager;

import com.obb.jpa.jpaturorial.entity.Employee;
import javax.ejb.*;
import javax.persistence.*;

/**
* @author Oscar Blancarte
*/
public class EmployeeApplicationDAO {

private EntityManager manager;

public EmployeeApplicationDAO() {
EntityManagerFactory emf = Persistence.createEntityManagerFactory("JPA_PU");
manager = emf.createEntityManager();
}

public Employee getEmployeeById(Long empId) {
return manager.find(Employee.class, empId);
}

public void updateEmployeeName(Long empId, String newName) {
//Se abre la transacción manualmente
manager.getTransaction().begin();
Employee emp = manager.find(Employee.class, empId);
emp.setName(newName);
//Se cierra la transacción manulamente
manager.getTransaction().commit();
}
}

Podemos apreciar que el constructor de la clase estamos creando manualmente el EntityManager en lugar de simplemente inyectarlo como el Container-Managed, la otra diferencia es en el método updateEmployeeName, ya que para poder persistir los cabios tenemos que abrir y cerrar la transacción con los métodos beign y commit.

JTA es sin duda unas de las API menos conocidas del Estándar de Java, pues si funcionamiento es abstraído casi en la totalidad por el Application Server, sin embargo, no puedo hacer todo el solo, y es necesario conocer cómo funciona y como indicarle a JTA como trabajar con las tracciones.

Lo primero que debemos de saber es que JTA trabajo de la mano con los Enterprise Java Beans (EJB) a partir de la versión 3.0, mediante la unión de EJB + JPA + JTA, es posible crear componentes de negocio súper potentes y lo más interesantes, totalmente transaccionales. Esto quiere decir que todas las operaciones que realicemos en la invocación de un EJB queda envuelto es una transacción, sin importar cuantos EJB se ejecuten en la misma invocación o en varías. Te recomiendo repasar la sección anterior, EntityManager & PersistenceContext ya que te pondrá un poco en contexto sobre los Transaction-Scope.

En la imagen anterior podemos apreciar cómo es que JTA administra las transacciones. El cliente invoca un servicio de negocio, antes de que el Application Server inicie la ejecución del EJB, este abre una transacción, seguido se ejecuta una serie de EJB los cuales pueden hacer múltiples operaciones sobre la base de datos. Cuando la ejecución de todo el flujo termina, el Servidor realiza un Commit y regresa los resultados al cliente.

Cabe mencionar que lo explicaremos a continuación requiere de conocimientos previos de EJB, pues JTA se integra junto con JPA para crear una amalgama perfecta, donde es difícil entender dónde empieza uno y termina el otro. Además, esta no es una guía de EJB por lo que nos detendremos en explicar la teoría de EJB.

Java Transaction API (JTA)

Antes de empezar debemos de dejas claro que JTA solo funciona en ambientes de Java EE, pues es el Application Server quien administra las transacciones a través de JPA. En la siguiente sección hablaremos de cómo administrar las transacciones en Ambientes Java SE, por lo que por ahora lo dejaremos hasta aquí. Para configurar JPA para que utilice JPA, tendremos que regresar al archivo persistence.xml y ajustar la línea:

<persistence-unit name=”JPA_PU” transaction-type=”JTA”>

Si bien JTA administrara las transacciones es importante decirle como, es por eso que aquí entra en juego la anotación @TransactionAttribute , la cual pude ser declarada en cada método de negocio o a nivel de clase. Existen 6 posibles valores, los cuales harán que el EJB Container funcione de forma diferente. Los valores son los siguientes:

• NOT_SUPPORTED: Indica que la operación no soporta transacciones, por lo que, si el método es ejecutado dentro de una transacción, esta se suspende durante la ejecución del método y se restaura una vez finalizado, por lo que todos los cambios realizados en estos métodos no serán persistentes.

• SUPPORTS: Indica que el método soporta transacciones, por lo que sí es ejecutado dentro de una transacción, este se unirá a la misma. Por otro lado, si es ejecutado fuera de una transacción este no creara ninguna transacción y todos los cambios realizados no se persistirán.

• REQUIRES_NEW: Indica que el método requiere forzosamente una nueva transacción para funcionar, por lo que se creará una nueva transacción independientemente de si es ejecutado dentro o fuera de una transacción existente.

• MANDATORY: Estas operaciones deberán ser ejecutadas forzosamente dentro de una transacción existente. En caso contrario se lanzará una Exception de tipo javax.ejb.EJBTransactionRequiredException.

• REQUIRED: Le indicamos que la operación requieres de una transacción, por lo que, si es ejecutado dentro de una transacción existente, este se unirá a la mima. Por otro lado, si no existe una transacción este creará una nueva.

• NEVER: Le indicamos que la operación por ningún motivo deberá ser ejecutado dentro de una transacción existente, ya que lanzará una Exception de tipo javax.ejb.EJBException. Si es ejecutado fuera de una transacción, tampoco creara una nueva.

Cuando @TransactionAttribute es declarada a nivel de clase, afectará a todas las operaciones definidas en el EJB, por otra parte, si es definida a nivel de método, solo afectara al método anotado. Cabe mencionar que se puede combinar definiendo la anotación a nivel de clase y luego en los métodos. El resultado será que la definición a nivel de método sobre escribirá a la de clase.

El siguiente código es un ejemplo rápido de cómo se apreciaría un EJB con la anotación @TransactionAttribute.

@EJB
@Stateful
@TransactionAttribute(TransactionAttributeType.REQUIRED)
public class EmployeeExtendedDAO implements IEmployeeDAO{

    @TransactionAttribute(TransactionAttributeType.NEVER)
    public Employee getEmployeeById(Long empId){
        //Se consulta el empleado mediante el ID
        return manager.find(Employee.class, empId);
    }
}

Podrías pensar que configurar las transacciones es muchos más complicado que solo anotar los métodos, pero la realidad es que tan solo eso es necesario, ya que el Application Server se encargará del resto. No voy a entrar un mucho detalle de cómo utilizarlas, pues tan solo es necesario definir la anotación en la clase o en los métodos, el resto queda del lado de EJB, por lo que dejaremos hasta aquí esta sección. y en la siguiente parte hablaremos de cómo gestionar las transacciones con Java SE.

Gran parte de la funcionalidad de JPA es expuesta por medio de la Interface EntityManager, de la cual ya hemos hablado con anterioridad, y es por medio de esta interface, que es posible realizar las operaciones básicas. Las operaciones o métodos que exponen EntityManager son persist, merge, remove, find entre otras, que son sin duda las operaciones que más utilizaremos los proyectos.

En la sección anterior de este tutorial, hablamos de los estados de las entidades, las cuales será clave para entender cómo y cuándo deberemos utilizar dichas operaciones.

Sin más, las operaciones se describen a continuación:

Método Persist

Mediante esta operación es posible persistir en la base de datos una nueva (new) Entidad, la cual ha sido creada recientemente o persistir una Entidad que se encuentra en el Persistence Context (Atached).

Esta operación la debemos de utilizar cuando queremos persistir una Entidad que ha sido creada recientemente mediante el operador new, o cuando queremos actualizar una Entidad que fue cargada previamente al Persistence Context o dicho de otra manera, para actualizar una Entidad en estado atached.

Veamos un ejemplo de cómo persistiríamos una nueva Entidad:

package com.obb.jpa.jpaturorial.exercises;

import com.obb.jpa.jpaturorial.entity.Employee;
import com.obb.jpa.jpaturorial.entity.Status;
import com.obb.jpa.jpaturorial.util.EntityManagerUtil;
import java.util.Calendar;
import javax.persistence.EntityManager;

/**
 * @author Oscar Blancarte
 */
public class CreateEmployee {

    public static void main(String[] args) {
        //Create new EntityManager
        EntityManager manager = EntityManagerUtil.getEntityManager();

        //Open Trnsaction
        manager.getTransaction().begin();

        Employee employee = new Employee();
        employee.setName("Oscar Blancarte");
        employee.setRegistDate(Calendar.getInstance());
        employee.setSalary(1000);
        employee.setStatus(Status.ACTIVE);
        
        //Persist Employee
        manager.persist(employee);
       
        //Commit Transaction
        manager.getTransaction().commit();
    }
}

En las líneas 16 y 19 creamos el EntityManager y abrimos una nueva transacción, En las líneas 21 a 25, creamos un nuevo Empleado y establecemos sus propiedades, seguido utilizamos la instrucción manager.persist(employee)  para marcar la entidad para ser persistida, finalmente en la línea 31 cerramos la transacción. Observemos que tan solo es necesario pasar la Entidad como parámetro para que JPA realice la inserción.

Método Merge

La operación merge es utiliza para actualizar una entidad existente que no pertenece a un Contexto de persistencia. Esta operación la debemos utilizar cuando queremos actualizar una entidad que ya existe en la base de datos, pero por algún motivo, esta no está dentro del Contexto de Persistencia, este escenario se da cuando utilizamos DTO para viajar la información del FrontEnd al BackEnd, en donde convertimos el DTO a una Entidad y esta entidad ya existe en la base de datos. Veamos como utilizamos esta operación:

package com.obb.jpa.jpaturorial.exercises;

import com.obb.jpa.jpaturorial.entity.Employee;
import com.obb.jpa.jpaturorial.entity.Status;
import com.obb.jpa.jpaturorial.util.EntityManagerUtil;
import java.util.Calendar;
import javax.persistence.EntityManager;

/**
 * @author Oscar Blancarte
 */
public class UpdateEmployee {
    public static void main(String[] args) {
        //Create new EntityManager
        EntityManager manager = EntityManagerUtil.getEntityManager();
        
        //Query Employee by ID
        
        //Open Transaction
        manager.getTransaction().begin();
        
        //Set Employee Status
        Employee employee = new Employee();
        employee.setId(1L);
        employee.setName("Oscar Blancarte");
        employee.setRegistDate(Calendar.getInstance());
        employee.setSalary(1000);
        employee.setStatus(Status.INACTIVE);
        
        //Update Employee Status
        manager.merge(employee);
        
        //Commit changes
        manager.getTransaction().commit();
    }
}

Veamos que este ejemplo es prácticamente igual al ejemplo de la operación persist, sin embargo, existe una gran diferencia, en la línea 24 establecemos el ID de la entidad, lo que significa que cuando se realice el Merge, este se realice sobre el mismo registro. La segunda diferencia está en la línea 31, donde utilizamos la operación manager.merge(employee) .

Método Find

Esta operación es básica para buscar una Entidad solamente por su ID, mediante esta operación es posible recuperar la Entidad de la base de datos. Recordemos que una Entidad puede tener un ID de un solo campo o tener una llave compuesta, mediante @IdClass  y@EmbeddedId, cuando se trata de una llave simple, solo será necesario consultar la entidad por el valor de la llave primaria, sin embargo, cuando la llave es compuesta, el parámetro deberá ser del tipo de la llave primaria, es decir de la clase marcada como @IdClass  o @EmbeddedId . Veamos un ejemplo de cómo quedaría:

package com.obb.jpa.jpaturorial.exercises;

import com.obb.jpa.jpaturorial.entity.Employee;
import com.obb.jpa.jpaturorial.util.EntityManagerUtil;
import javax.persistence.EntityManager;

/**
 * @author Osccar Blancarte
 */
public class ReadEmployee {
    public static void main(String[] args) {
        //Create new EntityManager
        EntityManager manager = EntityManagerUtil.getEntityManager();
        
        //Query Employee by ID
        Employee employee = manager.find(Employee.class, 1);
        
        //Print name of Employee
        System.out.println("Employee name ==> " + employee.getName());
    }
}

Veamos que la operación find requiere dos parámetros, el primero es la clase de la entidad que esperamos buscar y el segundo valor es el ID. En este caso se trata de una llave simple, por lo que con mandar el valor 1 será suficiente, sin embargo, como mencione anteriormente, en caso se ser compuesta, deberemos mandar la clase que corresponde con la llave primaría.

Como resultado, la operación find retornara la Entidad con el ID = 1 con todas sus propiedades.

Método Remove:

La operación remove es muy simple, pues solo es requerido enviar la Entidad que se desea remover. La Entidad tendrá que estar dentro del contexto de persistencia para poder ser eliminada, de lo contrario nos arrojara una excepción. Veamos cómo utilizar esta operación:

package com.obb.jpa.jpaturorial.exercises;

import com.obb.jpa.jpaturorial.entity.Employee;
import com.obb.jpa.jpaturorial.util.EntityManagerUtil;
import javax.persistence.EntityManager;

/**
 * @author Oscar Blancarte
 */
public class DeleteEmployee {
    public static void main(String[] args) {
        //Create new EntityManager
        EntityManager manager = EntityManagerUtil.getEntityManager();
        
        //Query Employee by ID
        Employee employee = manager.find(Employee.class, 1L);
        
        //Open transaction
        manager.getTransaction().begin();
                
        //Delete Employee
        manager.remove(employee);
        
        //Commit transaction
        manager.getTransaction().commit();
    }
}

Lo primero que hacemos es consultar al Empleado mediante el la operación find, esto debidos a que la debemos de tener dentro del contexto de persistencia, seguido en la línea 22 ejecutamos la operación manager.remove(employee  lo cual provocara que la entidad sea eliminada de la base de datos y del contexto de persistencia.

Método Refresh:

Operación que permite actualizar la Entidad con la base de datos, tan solo es necesario mandar como parámetro la Entidad a actualizar, esto actualizará todos los atributos con los de la base de datos:

manager.refresh(employee);

No regresa nada, pues actualiza la misma entidad que se envió como parámetro.

Método Detach:

Operación que permite sacar una Entidad del Contexto de persistencia. Todo cambio realizado en la entidad será descartado al terminar la transacción.

manager.detach(employee);

La entidad queda en estado detached una vez ejecutada esta instrucción.

Método Clear:

Limpia el Contexto de Persistencia, por lo que todas las entidades pasarán al estado detached

Manager.clear();

Todos los cambios realizados en la transacción serán desechados.

Método Contains:

Operación que permite saber si una entidad se encuentra en el Contexto de persistencia. Se envía la Entidad a validar y retorna una booleano, indicando si está o no en el Contexto de Persistencia.

boolean exist = manager.contains(employee);

Existen muchas operaciones más que nos proporciona el EntityManager, pero estas las veremos gradualmente durante el desarrollo de este tutorial.

Entender el ciclo de vida de las Entidades es sin duda uno de los puntos cruciales de JPA, pues entender cómo es que una Entidad es gestionada por EntityManager nos permitirá entender mejor como es que JPA funciona y prevenir muchos errores en tiempo de ejecución.

Lo primero que debemos de entender, es que todas entidades que utilicemos con JPA, serán administradas por el EntityManager, es por este motivo que hemos agregado este esta sección al capítulo de EntityManager.

Persistence Context:

Antes de entrar a los estados de las Entidades es importante entender un nuevo concepto que no hemos analizados en esta guía, se trata del Contexto de persistencia (Persistence Context), este lo podemos ver como contenedor en donde se encuentra todas las Entidades administradas por el EntityManager. Cuando un nuevo EntityManager es creado a través del EntityManagerFactory este le asigna un Unidad de persistencia.

Cabe mencionar que el Persistence Context no es un objeto con el cual nosotros interactuaremos, ya que este esta encapsulado dentro de Entity Manager y solo a través de este es posible afectarlo. En la siguiente sección hablaremos de las operaciones que ofrece el Entity Manager y con las cuales es posible afectar a Unidad de persistencia y las entidades.

Estados de las entidades:

A medida que trabajamos con las entidades, estas van cambiando de estado, y el estado de estas será utilizado para realizar operaciones en la base de datos. Un aspecto importante cuando utilizamos JPA es que ya no estamos trabajando con sentencias SQL y en su lugar trabajamos con las Entidades y sus estados. Las entidades en JPA puedan pasar por cuatro estados distintos que se pueden ver en la siguiente imagen:

Los cuatro estados son:

• New: Estado que tiene una entidad cuando es creada con el operador new, por lo tanto, no existe en la base de datos y no está asociada a un contexto de persistencia. Todas las entidades en estado new no serán afectadas en la base de datos cuando la transacción finalice, pues no está asociado a al Context Persistence.
• Manage: Todas las entidades que están siendo administradas por JPA están en estado manage, lo que indica que son parte de un contexto de persistencia. Aplica para entidades que serán insertadas, actualizadas o fueron obtenidas por el EntityManager como parte de alguna operación SELECT.
• Detached: Las entidades en estado detached, son entidades que si existen en la base de datos, pero por algún motivo no son parte de un contexto de persistencia. Todas las entidades en este estatus no serán afectadas en la base de datos, pues no pertenecen a un Persistence Context
• Removed: Cuando una Entidad es marcada para ser eliminada, pasa automáticamente al estado de Removed. Cando la transacción finaliza, todas las Entidades en este status serán eliminadas de la base de datos y ya no existirán más en el Persistence Context.

En la siguiente sección hablaremos de las operaciones básicas que nos permite utilizar el EntityManager y con las cueles es posible mover de estados las entidades. Por lo pronto es importante entender los estados por lo que pueden pasar las entidades para que nos facilite entender las operaciones para buscar, persistir, actualizar y borrar de JPA.

En la práctica no es común utilizar esta anotación, debido a que las Entidades por lo general solo tiene los atributos que mapean con la base de datos. Sin embargo, existen ocasiones en donde puede ser útil. Un ejemplo muy habitual es cuando agregamos un logger a la clase entidad. Esta instancia de java.util.logging.Logger será una propiedad más de la entidad, pero no deseamos que sea persistente, para lo cual lo marcamos con @Transient. Retomaremos la Entidad Employee que hemos utilizado en todo este tutorial para analizar cómo quedaría:

package com.obb.jpa.jpaturorial.entity;

import java.util.Calendar;
import java.util.Objects;
import java.util.logging.Logger;
import javax.persistence.*;

/**
 * @author Oscar Blancarte
 */
@Entity
@Table(
    name = "EMPLOYEES" , 
    schema = "jpatutorial", 
    indexes = {@Index(name = "name_index", columnList = "name",unique = true)}
)
public class Employee {
    
    @Transient
    private static final Logger logger = Logger.getLogger(Employee.class.getSimpleName());
    
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY, generator = "EmployeeTable")
    @Column(name = "ID")
    private Long id;
    
    @Column(name = "NAME", nullable = false, length = 150)
    private String name; 
    
    @Column(name = "SALARY", nullable = false, scale = 2)
    private double salary;
    
    @Column(name = "REGIST_DATE", updatable = false, nullable = false)
    @Temporal(TemporalType.DATE)
    private Calendar registDate;
    
    @Column(name="STATUS", nullable = false, length = 8 )
    @Enumerated(value = EnumType.STRING)
    private Status status;
    
    @Column(name = "PHOTO" ,nullable = true)
    @Basic(optional = false, fetch = FetchType.EAGER)
    @Lob()
    private byte[] photo;
    
    /**
     * GETs and SETs
     */
}

Como vemos en la entidad Employee, marcamos la propiedad logger como @Transiente, de esta manera, este atributo será ignorado por JPA. Si ejecutamos el programa veremos que no se creara una columna para esta propiedad.

Tambíen los quiero invitar a ver mi curso de JPA, donde explico todos estos temas aplicados con API REST, https://codmind.com/courses/jpa

La anotación @Transient no tiene atributos, por lo que con solo agregarla JPA sabrá que debe ignorar el campo.

NOTA: Este artículo es solo una sección del Tutorial de JPA, para ver el contenido completo de este tutorial regresa al Índice en el botón de abajo.