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.

The post Relaciónes @ManyToMany appeared first on Oscar Blancarte - Software Architecture.

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.

The post Relaciones @OneToMany appeared first on Oscar Blancarte - Software Architecture.

Por increíble que parezca, en REST la URL puede proporcionar una de las principales fuentes de información para los servicios, pues es posible definir como parámetros de entrada ciertas parte de la URL, lo que nos permite en primer lugar, crear métodos especiales para atender ciertas URL, pero por otra parte, esos fragmentos de URL pueden ser inyectados como parámetros a los métodos Java.

NOTA: Este artículo pertenece a una guia completa para aprender a crear un API REST con el API de JAX-RS de Java, ve el índice completo aquí.

Hace unos días escribía sobre la forma de escribir los Path y como podemos como podemos podíamos definir parámetros con la anotación @Path, puede regresara a la sección Introducción a las URL con @Path si quieres tener un poco más de contexto sobre lo que estaremos hablando esta sección.

Definiendo un Path Param

No vamos a entrar en mucho detalle sobre como definir un parámetro desde @Path pues ya lo explicamos en una sección pasado, pero si repasaremos como se hacia. 

@GET
@Path("/users/{userId}")
public Response findUserById(long userId) {}

Como podemos apreciar en el fragmento de código anterior, es posible definir ciertas secciones de una URL como parámetros, encerrando entre llaves ({userId}) la parte que queremos recuperar como parámetro desde Java. 

Recuperar una Path Param con @PathParam

Ya que hemos definido todas secciones de parámetros dentro del @Path, lo que seguirá es recuperarlos desde el método Java para poderlos utilizar, para ello, debemos de establecer la anotación @PathParam en cada uno de los parámetros del método Java sobre el cual queremos inyectar el valor.

@GET
@Path("/users/{userId}")
public Response findUserById(@PathParam("userId") long user) {
    System.out.println("UserID ==> " + user);
}

En el fragmento de código anterior, podemos apreciar como hemos establecido la anotación @PathParam para el parámetro user, el cual será inyectado con el valor del parámetro userId del @Path.

Recuperar un Path param mediante UriInfo

La segunda forma de recuperar un Path param es mediante la interface UriInfo, la cual es una interface que contiene todos los metadatos relacionados con la URL. Al ser una interface no puede ser instanciada, por lo que deberá ser inyectada para ser utilizada, vamos como sería:

@GET
@Path("uriInfo/{param1}")
public Response getUriInfo(@Context UriInfo uriInfo) {
    String param1 = uriInfo.getPathParameters().getFirst("param1");
    return Response.ok(param1).build();
}

La interface UriInfo proporciona el método getPathParameters que retorna una subclase de la interface java.util.Map con todos los parámetros, por lo que podemos iterar el nombre de los parámetros y sus valores, o podemos buscar directamente el valor de un parámetro mediante el método getFist. 
Al ejecutar el método anterior deberíamos tener como resultado el valor del parámetro param1, vamos el resultado:

Conclusiones

Los Path params son indispensables para definir de forma clara los recursos de tu API, pues evita tener que agregar parámetros de tipo Query, los cuales hacen que las URL sean complejas y difíciles de recordar, ademas de que no son agradables para SEO.

The post Path params con @PathParam appeared first on Oscar Blancarte - Software Architecture.

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.

The post Personalizar las relaciones con @JoinColumn appeared first on Oscar Blancarte - Software Architecture.

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

The post Relación muchos a uno con @ManyToOne appeared first on Oscar Blancarte - Software Architecture.

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.

The post Introducción a Java Transaction API(JTA) appeared first on Oscar Blancarte - Software Architecture.

@Lob

La anotación @Lob es lo único que se requiere para indicarle a JPA que ese campo es un objeto pesado y que debe de tratarse como tal. Por lo general se utiliza con los arreglos de bytes, ya que permite almacenar cualquier cosa.

La anotación @Lob no tiene ningún atributo, por lo que solo será necesario definirla para que funcione. Otro punto importante es que esta anotación creará una columna de tipo longblob en mysql y podría variar según el manejador de base de datos utilizados, pero al final siempre será un campo para objetos pesados.

Para poner en práctica esta anotación, retomaremos la entidad Employee, en esta ya habíamos agregado la propiedad photo  de tipo byte[], en la cual vamos a almacenar la foto del empleado, sin embargo, no habíamos entrado en detalles. La entidad Employee se ve de la siguiente manera:

package com.obb.jpa.jpaturorial.entity;

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

/**
 * @author Oscar Blancarte
 */
@Entity
@Table(
    name = "EMPLOYEES" , 
    schema = "jpatutorial", 
    indexes = {@Index(name = "name_index", columnList = "name",unique = true)}
)
public class Employee {
    @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
     */
}

Observemos que @Lob es mucho más simple de lo que parece, sin embargo, recordemos que siempre serán necesarias las anotaciones @Column & @Basic para definir los atributos de la columna y la estrategia de carga. Por lo general las propiedades marcadas como @Lob son cargadas en la creación del objeto y no siempre es requerido el objeto pesado, por lo que es aconsejable utilizar la anotación @Basic y marcar el atributo como LAZY.

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

Finalmente, la tabla de empleados se vera de la siguiente manera:

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.

The post Trabajar con objetos pesados @Lob appeared first on Oscar Blancarte - Software Architecture.

@Basic

En JPA existe dos conceptos que son claves para entender cómo es que JPA carga los objetos desde la base de datos y estos son claves para mejorar el rendimiento de la aplicación, estos conceptos se explican a continuación:

• Lazy loading (Carga demorada): Los objetos de carga demorada no serán cargados desde la base de datos cuando el objeto sea creado, pero será cargado en cuanto se acceda a la propiedad. De esta manera JPA identifica cuando la propiedad es accedida por primera vez para cargar el valor desde la base de datos.
  • @Basic( fetch = FetchType.LAZY )
• Eager loading (Carga ansiosa o temprana): Este es la utilizada por default para la mayoria de las propiedades en JPA, a excepción de las colecciones las cuales las analizaremos mas adelante.
  • @Basic( fetch = FetchType.EAGER )

Lazy loading se logra mediante la utilización del patrón de diseño Proxy, el cual también explico con más detalle en mi libro.

La anotación @Basic define además la propiedad optional, la cual es de tipo booleano, si se le indica true, se decimos a JPA que esta propiedad es opcional y en ella puede haber un valor Null, en caso se ser false, le indicamos que la propiedad siempre deberá tener valor. Esta propiedad es más que nada para ayudar a JPA a optimizar los query para obtener los valores. Pero tendrá que corresponder con la realidad, ya que en caso de marcar que no es opcional y este valor es null en la base de datos JPA marca error.

NOTA: optional  es diferente  de nullable  de @Column, pues nullable sirve para definir la estructura de la columna y optional son sugerencias a JPA para optimizar los querys. Nunca debemos de confundir eso.

Un punto importante es que @Basic se puede emplear prácticamente para cualquier como tipos primitivos, clases wrapper, Calendar, enums, Time, Date, Timestamp. byte[], char[], clases que implementan java.lang.Serializable, etc.

Ya con toda la teoría, pasaremos a ponerla en práctica. Retómenos la clase Employee que hemos utilizando en todos el tutorial para agregar una nueva propiedad llamada photo, esta será de tipo bute[] y guardara el binario de la foto del empleado. La foto al ser un campo pesado lo marcaremos como LAZY, para evitar que se cargue al crear el objeto y solo cuando sea necesario se cargue. Por otra parte, la foto del empleado no es obligatoria por lo que definiremos la propiedad optional = true.  Veamos cómo quedaría:

package com.obb.jpa.jpaturorial.entity;

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

/**
 * @author Oscar Blancarte
 */
@Entity
@Table(
    name = "EMPLOYEES" , 
    schema = "jpatutorial", 
    indexes = {@Index(name = "name_index", columnList = "name",unique = true)}
)
public class Employee {
    @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
     */
}

Veamos que la anotación @Column se define para indicar el nombre de la columna de la base de datos y está definida la propiedad nullable=true debido a que la foto no es obligatoria. Recordemos la diferencia entre nullable & optional que ya analizamos.

NOTA: En la siguiente sección describiremos la anotación @Lob, por lo pronto solo dejémosla pasar por alto.

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

Finalmente, y tras ejecutar la aplicación para creer las tablas, veremos que la tabla queda de la siguiente manera:

La columna PHOTO se ha creado de tipo Longblob debido a que la propiedad es de tipo byte[] y puede ser de gran tamaño.

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.

The post Estrategias de carga con @Basic appeared first on Oscar Blancarte - Software Architecture.

Mediante la anotación @Temporal es posible mapear las fechas con la base de datos de una forma simple. Una de las principales complicaciones cuando trabajamos con fecha y hora es determinar el formato empleado por el manejador de base de datos. Sin embargo, esto ya no será más problema con @Temporal.

Mediante el uso de @Temporal es posible determinar si nuestro atributo almacena Hora, Fecha u Hora y fecha, y es posible utilizar la clase Date o Calendar para estos fines. Yo siempre recomiendo utilizar Calendar, pues tiene muchas más operaciones para manipular fecha y hora.

Se pueden establecer tres posibles valores para la anotación:

• DATE: Acotara el campo solo a la Fecha, descartando la hora.
  • @Temporal(TemporalType.DATE)
• TIME: Acotara el campo solo a la Hora, descartando a la fecha.
  • @Temporal(TemporalType.TIME)
• TIMESTAMP: Toma la fecha y hora.
  • @Temporal(TemporalType.TIMESTAMP)

Para ejemplificar como utilizar esta anotación retomaremos la Entidad Employee que ya hemos venido utilizando en todo este tutorial. En el pasado ya habíamos agregado un atributo llamado registDate que representaba la fecha de ingreso del empleado, pero no habíamos entrando en detalle, por lo que ahora será tiempo de regresar y analizarlo. Veamos como dejamos la entidad Employee:

package com.obb.jpa.jpaturorial.entity;

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

/**
 * @author Oscar Blancarte
 */
@Entity
@Table(
    name = "EMPLOYEES" , 
    schema = "jpatutorial", 
    indexes = {@Index(name = "name_index", columnList = "name",unique = true)}
)
public class Employee {
    @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;
    
    /**
     * GETs and SETs
     */
}

En este caso hemos determinado que la fecha de ingreso es solo fecha (DATE) puesto que no es de nuestro interés la hora. Observemos también que hemos definido la anotación @Column para definir el nombre de la columna contra la que mapea.

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

Veamos cómo quedaría la tabla generada hasta el momento:

Observa la columna REGIST_DATE es de tipo DATE.

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.

The post Mapeo de fechas con @Temporal appeared first on Oscar Blancarte - Software Architecture.

• Los dos objetos son de la misma clase.
• El valor de su ID (@Id) son iguales

Si estas dos condiciones se cumplen entonces las dos entidades son iguales sin importar que no hagan referencia a mismo objeto en memoria. Debido a esto, es que es importante sobrescribir estos dos métodos para que evalúen a una Entidad por las dos condiciones mencionadas.

Implementando los métodos hashCode & equals

Algo que me ha llamado mucho la atención es que a pesar de que estos dos métodos son básicos y que se utilizan con regularidad, muchas personas no entienden como trabajan internamente y aún menos como sobrescribirlos correctamente, si eres una de esas personas, no te preocupes ya que los IDE’s ya tiene por default utilidades que nos ayudan a generarlos de forma adecuada.
Lo primero que haremos será abrir la entidad Employee que hemos venido trabajando a lo largo de este tutorial. Luego presionaremos Source > Insert Code del menú principal, esto arrojara una pequeña lista de acciones, seleccionamos la opción equals() and hashCode(). Nos arrojara una pantalla como la siguiente:

En esta pantalla debemos todos los campos que conformen el ID de la Entidad, en este caso solo sería el atributo ID, lo seleccionamos en las dos listas como aparece en la imagen anterior, y presionamos generate. Esto concluirá la generación de los dos métodos y se deberán de ver así:

package com.obb.jpa.jpaturorial.entity;

import java.util.Objects;
import javax.persistence.*;

/**
 * @author Oscar Blancarte
 */
@Entity
@Table(
    name = "EMPLOYEES" , 
    schema = "jpatutorial", 
    indexes = {@Index(name = "name_index", columnList = "name",unique = true)}
)
public class Employee {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY, generator = "EmployeeTable")
    private Long id;
    private String name; 

    @Override
    public int hashCode() {
        int hash = 7;
        hash = 29 * hash + Objects.hashCode(this.id);
        return hash;
    }

    @Override
    public boolean equals(Object obj) {
        if (this == obj) {
            return true;
        }
        if (obj == null) {
            return false;
        }
        if (getClass() != obj.getClass()) {
            return false;
        }
        final Employee other = (Employee) obj;
        if (!Objects.equals(this.id, other.id)) {
            return false;
        }
        return true;
    }

     /**
     * GETs and SETs
     */
}

El método hashCode regresará un hash generado a partir del ID, veamos que en la ecuación interviene un variable hash con valor 7. No te preocupes por eso, es solo un número generado al azar.

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

Por otra parte el método equals lo primero que hará será comparar los dos objetos con el operador ==, este operador se traduce en la llamada del método hashCode de tal manera que this == obj sería igual a this.hashCode() == obj.hashCode(), y como va vimos el hashCode se genera a partir del ID y no a la posición de memoria, por tal motivo la expresión solo sería verdadera en caso de ambos objetos tengan el mismo ID.

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.

The post JPA y los métodos hashCode & equals appeared first on Oscar Blancarte - Software Architecture.