Ciclo de vida de las Entidades

Tutorial de JPA persistence.xml

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. as

El concepto Inversion of Control

Seguramente muchos de nosotros ya hemos escuchado el término Inversion of control (Inversión de control) más de una vez, incluso otros, ya los están utilizando sin saberlo. Lo cierto es que cada vez es más común escuchar este término y es que ha revolucionado por completo la forma trabar con los Frame Works.

Inversion of control (IoC) es una forma de trabajar que rompe con el formato tradicional, en donde el programar es el encargado de definir la secuencia de operaciones que se deben de realizar para llegar a un resultado. En este sentido el programador debe conocer todos los detalles del framework y las operaciones a realizar en él, por otra parte, el Framework no conoce absolutamente nada de nuestro programa. Es decir, solo expone operaciones para ser ejecutada. La siguiente imagen muestra la forma de trabajo normal.

 

inversion of control

as

Atributos volátiles con @Transient

Tutorial de JPA persistence.xmlLa anotación @Transient se utiliza para indicarle a JPA que un atributo de una Entidad no debe de ser persistente, de esta manera, JPA pasa por alto el atributo y no es tomado en cuenta a la hora de persistir el Objeto.

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

as

Trabajar con objetos pesados @Lob

Tutorial de JPA @LobJPA nos permite mediante la anotación @Lob mapear con la base de datos objetos pesados, como podría ser imágenes, xml, binarios, cadenas de texto extensas, json, etc. Cualquier objeto que pueda tener un tamaña muy grande o de longitud indefinida.

@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:

as

La etiqueta figure de HTML5

html5La etiqueta <figure>  permite agregar contenido variado asociadas a una descripción o título, el cual es asociado semánticamente a este, de tal forma que podemos agregar una imagen, ilustración, diagrama, o incluso código. Como regla general, el contenido que agreguemos debe de estar relacionado al texto principal de la página.

Un claro ejemplo donde se puede emplear <figure>  es para agregar imágenes a un artículo, donde las imágenes tienen por lo general una descripción justo por debajo. Un claro ejemplo sería cualquier artículo de Wikipedia, ya que este inserta a lo largo de todas sus secciones imágenes que tiene que ver con el texto en cuestión.

Actualmente <figure>  es más utilizado para representar imágenes, porque es lo más común en una página además del texto, pero es importante resaltar que se puede utilizar para representar cualquier contenido. La clave de <figure>  es que nos permite asociar cualquier cosa con una descripción, de tal forma que son asociados semánticamente.

La etiqueta <figure>  se utiliza en conjunto con la <figcaption>  para representar la descripción del contenido. La etiqueta <figure>  puede tener cualquier contenido seguido de <figcaption>  o al revés, <figcaption>  seguido de cualquier contenido. as

Estrategias de carga con @Basic

Tutorial de JPA @Basic@Basic es una anotación que nos permite controlar el momento en que una propiedad es cargada desde la base de datos, evitando que traer valores que no son necesario al momento de cargar el objeto. Esta anotación es utilizada generalmente para anotar objetos pesados, como una imagen o un archivo binario.

@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 )

as

Mapeo de fechas con @Temporal

Tutorial de JPA @Temporal

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)

as

HTML5, antecedentes y novedades

html5

La historia de HTML ha sido larga, ya que desde su nacimiento al principio de los 90, ha evolucionado muchísimo, pasando de ser tan solo un simple sistema para compartir documentos, a ser la base completa de la WEB.

HTML fue desarrollado inicialmente por Tim Berners-Lee en 1980, que trabaja en aquel entonces en la CERN (Organización Europea para la investigación Nuclear). El propuso un sistema de Hipertexto que permitiera compartir documentos de una manera más fácil y eficiente. Pero no fue hasta que se unió con Robert Cailiau para presentar su propuesta como la World Wide Web (W3), en un concurso para definir el sistema de hipertexto que se utilizaría para internet.

as

JPA y los métodos hashCode & equals

Tutorial de JPA persistence.xmlPor defecto, todos los objetos en Java heredan de la case Object los métodos hashCode y equals los cuales sirvan para identificar si dos variables hacen referencia al mismo objeto.
El comportamiento de facto del método hashCode retorna la posición en memoria de un objeto, y el método equals compara el hashCode de los dos objetos evaluados, de esta forma, si las dos variables hacen referencia a la misma posición de memoria, entonces se dice que son igual, de lo contrario son diferentes.
En el caso de las Entidades, la implementación default de estos métodos no funciona correctamente, debido a que una Entidad de dice que es igual a otra si se cumplen dos condiciones:

• 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:
Método equals y hashcode as

sql injection, tu página esta en peligro

SQL Injection

Probablemente hallas escuchado el termino SQL Injection  o Inyección de SQL y es que es uno de los ataques más frecuentes a los sistemas informáticos en la actualidad. Pero que es exactamente SQL Inyección y cómo es que un Hacker puede aprovechar esta vulnerabilidad para atacar los sistemas. Pues estas preguntas las resolveremos en este artículo.

 

La inyección de código es el método por medio del cual es posible infiltrar código SQL a través de los parámetros que utilizan las aplicaciones para generar las consultas en el BackEnd. La inyección es posible debido a al descuido o la ignorancia a la hora de escribir el código, dejando vulnerable a la aplicación para recibir “parámetros” que en realidad son sentencias de SQL adicionales, que luego son ejecutadas en la base de datos si el conocimiento de los administradores del sistema.

 

Este tipo de ataques se da en aplicaciones que generan las instrucciones SQL al vuelo o cuando se concatenan los parámetros a una instrucción base sin las debidas precauciones. Pero para entender mejor como es que se da este tipo de ataques es necesario conocer la anatomía de una instrucción SQL, para lo cual veamos la siguiente imagen:

 

SQL injection - base

as