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.

Las relaciones One to One (@OneToOne) se caracterizan porque solo puede existir una y solo una relación con la Entidad de destino, de esta forma, la entidad marcada como @OnoToOne deberá tener una referencia a la Entidad destino y por ningún motivo podrá ser una colección. De la misma forma, la Entidad destino no podrá pertenecer a otra Instancia de la Entidad origen.

Solo para ponernos en contexto, las relaciones @OneToOne se utilizan cuando existe una profunda relación entre la Entidad origen y destino,de tal forma que la entidad destino le pertenece a la Entidad origen y solo a ella, por ende, la existencia de la entidad destino depende de la Entidad origen.

Para comprender mejor todo este trabalenguas, analicemos el caso práctico de una factura, cuando creamos una factura, la llevamos con nuestro cliente para que la pague, este pago puede ser una entidad por separada que lleve el control de la fecha de pago, monto pagado, método de pago, etc. Veamos como quedarían esta Entidades

Entidad Invoice:

package com.obb.jpa.jpaturorial.entity;

import java.util.Calendar;
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;

    /** GET and SET */
    
}

Entidad Payment:

package com.obb.jpa.jpaturorial.entity;

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

/**
 * @author Oscar Blancarte <oscarblancarte3@gmail.com>
 */
@Entity
@Table(name = "payments")
public class Payment {
    
    @Id
    @Column(name = "ID")
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;
    
    @Temporal(TemporalType.TIMESTAMP)
    @Column(name="PAY_DATE", nullable = false, updatable = false)
    private Calendar payDate;
    
    @Column(name = "AMOUNT", nullable = false, updatable = false)
    private double amount;
    
    @Column(name = "PAY_METHOD", nullable = false, updatable = false)
    private PaymentMethod paymentMethod;
    
    @OneToOne
    @JoinColumn(name = "FK_INVOICE", updatable = false, nullable = false)
    private Invoice invoice;

    /** GET and SET */
}

Estas dos Entidades crearán las siguientes tablas:

Como podemos observar, la tabla payments tiene la columna FK_INVOICE que hace relación con la tabla invoices.

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

Algo que hay que tomar en cuenta, es que tanto la Entidad Invoice como Payment tiene anotada como @OneToOne a la otra entidad, sin embargo, solo payments ha creado la columna para hacer el JOIN, esto se debe a que esta es la que tiene la anotación @JoinColumn, la cual nos permite establecer como se llamará la columna para realizar el JOIN, adicional, la Entidad Invoice tiene definida la propiedad mappedBy de la anotación @OneToOne, esta propiedad es muy importante, pues le permite hacer una relación bidireccional, si no la pusiéramos, JPA agregaría una columna adicional en la tabla invoices, y guardaría el pago como un nuevo registro.

Veamos un ejemplo de cómo se crearía un registro con esta relación:

public static void main(String[] args) {
        EntityManager manager = EntityManagerUtil.getEntityManager();
        
        Customer customer = new Customer();
        customer.setName("Oscar Blancarte");
        
        Payment payment = new Payment();
        payment.setAmount(100);
        payment.setPayDate(Calendar.getInstance());
        payment.setPaymentMethod(PaymentMethod.CASH);
                
        
        Invoice invoice = new Invoice();
        invoice.setCustomer(customer);
        invoice.setRegistDate(Calendar.getInstance());
        invoice.setStatus(Status.ACTIVE);
        
        payment.setInvoice(invoice);
        invoice.setPayment(payment);
        
        manager.getTransaction().begin();
        manager.persist(invoice);
        manager.getTransaction().commit();
    }

Dando como resultado lo siguiente:

Conclusiones

Crear relaciones OneToOne es muy simple como hemos podido comprobar, e incluso, podríamos crear una relación unidireccionar omitiendo la propiedad payment de la entidad Invoice, lo que diera como resultado exactamente la misma estructura de base de datos, con la única limitante que no podríamos recuperar el pago por medio de la factura y es por ello que utilizamos relacionar bidireccionales con mappedBy.

The post Relaciones @OneToOne 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.

Las bases de como servicio también son parte de los Backend as a Service (BaaS).

Que es MongoDB Atlas

MongoDB Atlas es el primer servicio de “Database as a Services” (DaS) para bases de datos MongoDB, en el cual es posible crear completos clusteres (Replica Set) de bases de datos, con unos cuantos click y exponerlas por internet para contactar nuestras aplicaciones si la necesidad de las tareas de instalación y administración.

Como funciona MongoDB Atlas

MongoDB Atlas es una plataforma autogestionado, lo que quiere decir que ellos se encargarán de absolutamente todos los aspectos relacionados al hosting, instalación y actualizaciones, de tal forma que nosotros solo nos encargamos de las configuraciones más básicas, como gestionar los accesos, crear las bases de datos, crear alertas, etc.

Como crear un cluster

Crear un Cluster es sumamente fácil, pues solo se tiene que realizar unos simple pasos. El primero es seleccionar el hosting. Los proveedores soportados son Amazon Web Services (AWS), Google Cloud Platform, Microsoft Azure:

El segundo paso es seleccionar la región en la que estará “hosteado” nuestra Base de datos. La ubicación es muy importante para mejorar el performance de nuestra aplicación, por lo que tendremos que seleccionar la esté más cercas de nuestra aplicación o de nuestros usuarios.

El siguiente paso es seleccionar las características del servidor, entre los que tenemos un cluster totalmente gratuito:

Finalmente es posible establecer algunas configuraciones adicionales, como el backup, la versión de MongoDB, seleccionar el nombre del custer, etc.

Una vez creado el cluster es posible monitorearlo y sabes datos como el número de operaciones y número de conexiones

Conectarnos la MongoDB Atlas:

El paso final será conectarnos a la base de datos, para eso, MongoDB Atlas nos ofrece la opción de conectarnos mediante la herramienta Mongo Shell, conectar nuestra aplicación mediante un Driver o utilizar un cliente como Compas:

Conclusiones

Como podrás ver, utilizar MongoDB Altas es sumamente fácil, pues solo nos preocupamos por desarrollar nuestra aplicación, en lugar de perder tiempo en gestionar e instalar nuestra base de datos, al mismo tiempo que Atlas se encargar de asegurar la alta disponibilidad de la base de datos.

Aprende más sobre MongoDB y MongoDB Atlas en mi libro “Aplicaciones Reactivas con React, NodeJS & MongoDB”

The post MongoDB Atlas – Database as a Service appeared first on Oscar Blancarte - Software Architecture.

Hoy en día hablar de bases de datos sin pensar en Tablas y Columnas es muy difícil de imaginas, pues la gran mayoría de nosotros crecimos con bases de datos relacionales, como lo son Oracle, MySQL y SQL Server. Sin embargo, como todas las tecnologías, llega el momento, en que nuevas tecnologías, van desplazando a las anteriores.

Así como las bases de datos relacionales remplazaron a las bases de datos sobre archivos de texto plano, las bases de datos no estructuras están empezando a tomar un protagonismo muy importante, incluso, es posible que, en un futuro no muy lejana, las bases de datos NoSQL empiecen a remplazar desplazar a las bases de datos tradicionales.

Hoy en día, han surgido barías propuestas alternativas al modelo SQL, como lo son, Base de datos de Objectos (ObjectDB), Bases de datos de clave-valor (Cassandra), base de datos en tiempo real (Firebase) y bases de datos de documentos (MongoDB), las cuales, a pesar de trabajar de forma diferente, tiene algo en común, y es que todas son Bases de datos NoSQL.

Este solo un es fragmento de mi articulo en la revista Centripio Magazine, te invito a que la descargues y te suscribas.

The post MongoDB y el paradigma NoSQL appeared first on Oscar Blancarte - Software Architecture.

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

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

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

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

EntityManager manager = factory.createEntityManager();

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

 Trabajar con Transacciones Resource Local

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

package javax.persistence;

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

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

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

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

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

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

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

The post JPA – Resource Local transaction appeared first on Oscar Blancarte - Software Architecture.

Ahora bien, para maximizar la portabilidad y facilitar las librerías utilizaremos un Maven, la cual es una herramienta para la gestión de dependencias y construcción de proyectos similar a Apache Ant, aunque más potente. Si quieres aprender más de Maven te recomiendo el libro Maven: The Definitive Guide.

Por el momento no te preocupes si no has trabajado con NetBeans o Maven, ya que aquí mismo te diremos paso a paso como hacer todos los pasos para configurar tu proyecto.

Creando un proyecto Maven

Lo primero que tendremos que hacer será abrir NetBeans y en el menú superior pincharemos la opción File >New Project  y nos arrojara la siguiente pantalla:

De la lista de categorías seleccionemos Maven y en la lista Projects, selecciones Java Application, seleccionamos Next y nos arrojara la siguiente pantalla:

En esta nueva pantalla configuraremos el nombre del proyecto y los demás datos necesarios para la generación de los Artefactos de Maven, en este caso, capturemos los datos como aparecen en la imagen. No te preocupes si no comprendes Maven, solo sigue la guía y te explicaremos todo lo que sea relevante para la configuración. Finalmente, presiona Finish para finalizar el wizard y crear nuestro proyecto.

Ya en este punto nuestro proyecto JPATutorial esta creado y lo puedes visualizar en la sección izquierda del IDE. Por ahora es tan solo un proyecto Java por lo que solo tendremos disponibles las librerías del JRE Estándar Edition. JPA por otra parte es parte de la especificación de Java EE por lo que será necesario realizar la importación de las librerías adecuadas. Es en este punto donde Maven hace su magia.

Para importar las librerías de JPA será necesario seleccionar la carpeta Dependencias que aparece dentro del proyecto y seleccionamos la opción Add Dependency y nos aparecerá una pantalla como la siguiente:

Escribimos EclipseLink en el campo Query y presionamos enter, esto iniciara una búsqueda de todas las librerías registradas en los repositorios de Maven, la primera vez que realizamos una búsqueda puede tardar un tiempo considerable, debido a que debe de descargar todo el listado de dependencias. Una vez que arroja los resultados, expandimos el ítem org.eclipse.persistence : eclipselink, y nos arrojara una serie de artefactos, seleccionamos la última versión disponible  del JAR, en este caso, sería la 2.6.4 [jar] y presionamos Add, este proceso iniciara con la descarga de las dependencias de forma automática y las registrara en nuestro proyecto.

Tras esperar un momento a que se descarguen las librerías, podrás ver dentro de la carpeta Dependencies todas las librerías descargadas, y tu proyecto se deberá de ver de la siguiente manera:

Repetiremos los pasos anteriores para agregar el driver de MySQL, y así poder establecer conexión más adelante, en este caso buscamos mysql y seleccionamos el ítem mysql: mysql-connector-java, seleccionamos la versión que adapte a la versión de MySQL que estamos utilizando, en este caso es la 6.0.4 [jar]

Finalmente, el archivo pom.xml que se encuentra en la carpeta Project Files se vera de la siguiente manera:

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>
    <groupId>com.obb.jpa</groupId>
    <artifactId>JPATurorial</artifactId>
    <version>1.0-SNAPSHOT</version>
    <packaging>jar</packaging>
    <dependencies>
        <dependency>
            <groupId>org.eclipse.persistence</groupId>
            <artifactId>eclipselink</artifactId>
            <version>2.6.4</version>
        </dependency>
    </dependencies>
    <properties>
        <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
        <maven.compiler.source>1.8</maven.compiler.source>
        <maven.compiler.target>1.8</maven.compiler.target>
    </properties>
</project>

NOTA: El archivo POM es generado para todos los proyectos Maven y es desde este archivo donde se configuran las dependencias, las instrucciones de generación del proyecto y hasta la forma de ejecución/despliegue de la aplicación.

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 punto, nuestro proyecto JPA está listo para poder empezar a utilizar JPA, en la siguiente sección nos introduciremos en la clase EntityManager y la configuración del archivo persistence.xml

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 Crear un proyecto JPA appeared first on Oscar Blancarte - Software Architecture.

Sin embargo existen casos concretos en los que es necesario actualizar mas de una base datos en una sola operación, un caso muy tipo es SOA, debido a que es común la necesidad de transaccionar con mas de una base de datos al mismo tiempo.

Este tipo de transacciones pueden ser delicadas debido a que si hacemos commit en la primera, pero la segunda falla, tendremos un problema de integridad, ya que la primera base de datos habrá aplicados los cambios en el commit y la segunda base de datos realizara un RollBack, deshaciendo todos los cambios.

2Phase Commit o Commit de dos faces.

Para resolver el problema que acabamos de ver, es necesario utilizar transacciones distribuidas con un Commit de dos faces.

El 2Phase Commit o Commit de dos faces se diferencia de un commit normal en que este engloba un una sola transacción los cambios realizados en dos o mas base de datos a la vez(XA Transaction). Para realizar esto, cada manejador de base de datos abrirá una transaccion de forma separada. El coordinador de la transacción les solicitara a todos los manejadores de base de datos que se preparen para el commit( Paso 1), en este punto cada base de datos esta lista para hacer el commit, Si todos los manejadores pasan por el paso 1 de forma positiva, entonces el coordinador de la transacción solicitara el commit a todos los manejadores. Al final, si todos las base de datos realizan el commit, entonces la transaccion sera exitoso y se habrá realizado una transaccion global.

Otro escenario es cuando alguno de los manejadores falla durante la preparación al commit, por lo cual toda la transacción falla y todos los manejadores dan un Rollback a la transacción.

Escenario practico:

Para ilustrar esto de una forma mas practica, hablaremos de un ejemplo concreto donde se podria utilizar una transaccion distribuida o XA Transaction.

Imaginemos que tenemos dos sistemas, el sistema de nomina y el contable, sin embargo requerimos realizar un servicio que nos permita crear un usuario, pero que este usuario sea valido para los dos sistemas, para lo cual el servicio tendrá que escribir en la base de datos de los dos sistemas para crearlos. Desde luego que es importante que si la creación falla en algunos de los dos, el usuario no deberá crearse en ninguno de los dos sistemas.

Acabamos de ver un ejemplo simple donde podemos utilizar un commit de dos faces, sin embargo pueden existir muchos mas escenarios donde sea necesario transaccionar dos o hasta mas base de datos a la vez.

Conclusiones:

Las ventajas que ofrecen el 2Phase commit son muy grandes, ya que nos permite realizar transacciones globales con mas de una bases de datos a la vez, Ya solo dependerá de nosotros utilizarlas sabiamente, ya que en ambientes de integración siempre es mas recomendable utilizar servicios que conexiones directas a la bases de datos de nuestros aplicativos.

The post 2Phase Commit appeared first on Oscar Blancarte - Software Architecture.