No es un secreto que las aplicaciones de hoy en día generan una gran cantidad de datos y sumado a eso, cada vez tenemos más aplicaciones independientes que van produciendo datos de forma aislada, por tal motivo, llegara un momento en que los datos están distribuidos en varias base de datos, por lo que recuperar información relevante y consistente, nos obliga a crear complejos procesos de extracción y cargado de datos (ETL) para integrarlos en una única fuente confiable para finalmente sea analizada y explotable, sin embargo, como analizaremos en este artículo, este enfoque tiene grandes problemas, entre los que destaca los complicados procesos de extracción y los múltiples procesos ETL que deben de correr una y otra vez para obtener diferente información para diferentes análisis o reportes.

Antecedentes

Cuando las herramientas como Business Intelligence (BI) comenzaron a ponerse de moda, predominaban las aplicaciones monolíticas, donde cada aplicación podía contener una gran cantidad de información sobre una parte del negocio:

Debido a que los sistemas eran grandes silos datos, era muy simple crear procesos ETL para extraer información de estos sistemas y crear los famosos Data warehouses o almacenes de datos, desde los cuales las herramientas de BI generaban sus reportes:

A pesar de que esto es suficiente para muchas empresas, el problema llega cuando se requieren reportes más complejos, donde la información se recolecta de múltiples sistemas para generar un solo reporte, creando una sobre carga de las bases de datos transaccionales, pues múltiples procesos extraen información para diferentes almacenes de datos:

Lo que estamos viendo en la imagen anterior es un caso muy común que he visto en muchas empresas, donde tiene varios procesos ETL que extraen información del mismo sistema, pero como son varios procesos, los tiene que programar a diferentes horas de la noche o del día para que no corran en simultaneo.

Si prestamos atención en la imagen anterior, podrás observar que el ERP es utilizado por 3 procesos ETL para crear diferentes almacenes de datos, y muy probablemente los 3 procesos ETL consulten prácticamente la misma información, pero la procesen de forma diferente, entonces, como la procesan diferente según su objetivo, hace necesario crear cuantos procesos ETL sea necesario para satisfacer todas las necesidades del negocio, lo cual, queda claro que no es para nada eficiente.

¿La solución es un Stagin Area?

Dada la problemática anterior, quizás los más experimentados digan, bueno, pues creamos un Stagin Area en donde volquemos todos los datos y sobre esa base de datos corremos los procesos ETL. Veamos como quedaría:

En esta nueva arquitectura tenemos proceso de extracción que solo extraen los datos una vez de los sistemas transaccionales y los dejan en los Stagin Area, los cuales al nos ser transaccionales, permite que múltiples procesos ETL se conecten a ellos para extraer la información y crear sus propios almacenes de datos. Este enfoque tiene varias ventas:

• Extraemos la información una sola vez de los sistemas transaccionales.
• Permite que los procesos ETL se conecten a los Stagin Area a la hora que sea sin comprometer la operatividad del negocio.
• Tenemos un mejor control sobre los procesos que extraen información de los sistemas transaccionales.

Entonces estarás pensando, listo, problema resuelto, cerremos todo y vamos a casa a descansar, sin embargo, hay una pequeña que no hemos sumado a la ecuación…. Los microservicios y las arquitecturas distribuidas, que es aquí donde todo comienza a complicarse, pues en lugar de tener grandes fuentes de datos, tenemos múltiples fuentes, donde cada una cuenta una parte de la historia y para poder tener toda la historia, necesitamos recopilar información de múltiples puntos.

Datalake

El problema ( o la ventaja, depende de como lo veas) es que en arquitecturas de microservicios no tenemos enormes sistemas desde los cuales obtener los datos, si no que es necesario recopilar datos de varias fuentes solo para poder crear un reporte:

Bajo esta arquitectura se hace impráctico tener múltiples Stagin Area, ya que se tendrían que mantener demasiadas bases de datos, por eso, se propone los Datalake o Lagos de datos, los cuales cambian considerablemente la forma en que los datos se extraen y se procesan.

Un lago de datos es básicamente un vertedero donde son las mismas aplicaciones quienes dejan los datos, en lugar de ser extraídos por un proceso, por otra parte, un Datalake es único, esto quiere decir todas las aplicaciones dejan los datos en el mismo lugar. Creando un lago de datos donde los demás procesos se pueden servir.

Este enfoque puede resultar controversial, pero a medida que avancemos en este artículo, iremos resolviendo algunas dudas que puedan surgir, así que por lo pronto, solo ve analizando esto.

Lo primero que debemos entender respecto al Datalake es que son las mismas aplicaciones las que deciden que información mandar al lago y el formato de la misma, por que cada aplicación es dueña de su parte del lago. De la misma forma, esta tiene la libertada de agregar, quitara o modificar la estructura de la misma, ya que cada aplicación determina que y como la información se envía al Datalake. Aunque claro, siempre será mejor no hacer cambios demasiados bruscos.

Otro aspecto del lago es que la información es incremental y no está procesada, esto quiere decir que los sistemas van depositando solamente la nueva información (aun que podrían borrar y cargar toda la data), pero al mismo tiempo, la información no está procesada al momento de dejarla en el lago, si no que se deja en bruto.

En este nuevo enfoque son los interesados los encargados en buscar que información les sirve y cual no, al mismo tiempo que se puede obtener información de múltiples aplicaciones de forma simultánea. Ha esto yo le llamo los ríos del lago, ya que cada interesado deshoja del lago la información que le sirve para su propósito para dejarla en un data warehouse ya procesada:

Este enfoque es especialmente útil en entornos de Big Data y análisis de datos, ya que todos los sistemas van depositando la data en bruto en un mismo lugar, lo que facilita para que los científicos de datos puedan explotar la información, además, es posible contrastarla con la data de los demás sistemas.

Reservas respecto a la seguridad

Uno de los aspectos más cuestionados sobre este enfoque es la seguridad de los datos, ya que una persona con acceso total al lago tiene visión completa de lo que pasa en todos los sistemas, lo cual no es una observación menor, por lo que hay que tener especia cuidado sobre los accesos que damos a este. No hay una formula clara o única para resolver esto, salvo que limitar bien el acceso al lago y tener acuerdo de confidencialidad bien estipulados.

The post Datalake una nueva forma de análisis de datos 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.

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.

The post Entity Manager & Persistence Context 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.

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.

The post Operaciones básicas appeared first on Oscar Blancarte - Software Architecture.

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.

The post Ciclo de vida de las Entidades 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.