Bitsmi Blog
SQL – Encapsulado de sentencias complejas
30-09-2016 - Antonio Archilla
En muchas ocasiones el acceso a un conjunto de datos almacenado en base de datos requiere de una consulta especialmente compleja. En los casos en que se debe permitir acceso a sistemas externos a estos datos, la solución ideal pasa por implementar una capa de negocio intermedia entre la aplicación consumidora de la información y la base de datos, sea mediante servicios web, un data-grid u otra componente que permita abstraer la complejidad de la obtención de los datos para facilitarla al sistema externo. Hay casos en que esto no es posible y por requerimientos de arquitectura en el sistema, las aplicaciones externas deben acceder directamente a la base de datos para obtener la información. En estos supuestos, es buena idea implementar una interfaz para la obtención de los datos, una API que permita crear una caja negra sobre la implementación real de la obtención de los datos. Con ello se consigue: Las modificación de las estructuras subyacentes de la base de datos no afectan a la integración con el sistema externo al mantenerse la interfaz de obtención de datos. Permite mantener el control de cómo se obtienen los datos, lo que minimiza la posibilidad de errores al estar centralizada en una única implementación. Ante la aparición de errores, se minimiza el tiempo necesario para la corrección, ya que estaría localizada en un único punto: La implementación de la interfaz. En este post se propone un posible mecanismo para construir estas interfaces de acceso aplicado a bases de datos Oracle.
SQL – Expresiones de Tablas Comunes (CTE)
14-08-2016 - Antonio Archilla
Las Expresiones de Tabla Común, en inglés Common Table Expressions (CTE), se pueden definir cómo la especificación de un conjunto de resultados temporales que se obtienen
a través de una subconsulta determinada. El ámbito de aplicación de este conjunto de datos queda restringido a una ejecución concreta de la instrucción SQL
en la que se encuentra definida (SELECT, INSERT, UPDATE o DELETE), momento a partir del cual, dichos resultados son eliminados del contexto de ejecución.
Dicho de una manera un tanto simplista y haciendo un símil con conceptos aplicables a la programación imperativa, sería cómo la definición de una subrutina local,
en el sentido que permite definir un código, en este caso una consulta que devuelve un conjunto de resultados determinados, asignarlo a un identificador determinado
y usarlo cómo referencia dentro de otras partes de la consulta principal.
Algunas de las ventajas que proporciona su utilización son:
- Permite evitar la reevaluación de una subconsulta que se ejecute múltiples veces dentro de la consulta principal
- Simplifica la escritura y legibilidad de consultas complejas en las que se realicen definiciones de tablas derivadas
(definidas dentro de la clausula
FROMcómo una subconsulta) en uno o múltiples niveles - Permite substituir la definición de vistas globales cuando sólo están restringidas a una sola consulta, ayudando a no ensuciar el espacio global de nombres con definiciones innecesarias
- Permite realizar operaciones de agrupación o condicionales sobre datos derivados de operaciones escalares o no deterministas. En este caso se podrá definir el cálculo de las operaciones requeridas dentro de la consulta CTE y posteriormente realizar las agrupaciones necesarias en la consulta principal o en otra CTE como si de valores de una tabla corriente se tratara
Aunque forma parte del estándard SQL-99, su implementación por parte de los motores de base de datos que soportan este estándar es opcional:
- Oracle: Soportado a partir de la versión 9i r2
- MS SQL Server: Soportado a partir de la versión 2008
- PostgreSQL: Soportado a partir de la versión 8.4
- SQLLite: Soportado a partir de la versión 3.8.3
- IBM DB2: Soportado
- MySQL y su derivada MariaDB no lo soportan aún
ResourceBundle – Localización de recursos
12-06-2016 - Antonio Archilla
La API estándar de Java provee de mecanismos para la localización de recursos (mensajes de texto, URLs a imágenes u otros recursos…) mediante la utilización de la clase ResourceBundle.
La forma más conocida y habitual de usarlos es a través de ficheros de propiedades, en los que se especifican los recursos a utilizar para cada localización en forma de clave – valor,
pero existen otras posibilidades, como por ejemplo la utilización de clases java.
OCP7 14 – Patrones de dseño en Java (Singleton, Factory y DAO)
27-03-2016 - Xavier Salvador
Gestión de dependencias Maven mediante la librería Aether
26-03-2016 - Antonio Archilla
Aether es una librería Java que permite integrar en cualquier aplicación Java el mecanismo de resolución de dependencias de Maven. Se trata de una forma mucho más simple de hacerlo que integrar la distribución completa de Maven o incrustar Plexus dentro de la aplicación.
La API de Aether provee funcionalidades para:
- Definir y gestionar de un repositorio local de artefactos.
- Recuperar artefactos desde múltiples repositorios remotos para su consumo local.
- Publicar artefactos locales en múltiples repositorios remotos.
- Resolver las dependencias transitivas de los artefactos.
- Inspeccionar el grafo de dependencias de un artefacto.
En este post se exponen ejemplos concretos de implementaciones para las funcionalidades anteriormente mencionadas.
Orden de ejecución de los métodos de un test de JUnit4
14-02-2016 - Antonio Archilla
Aunque quizá JUnit4 sea el framework de testing más extendido en el ecosistema Java, adolece de ciertas limitaciones de fábrica que según como se mire son difíciles de explicar. Una de ellas para mi gusto es la dificultad de poder marcar el orden de ejecución de los métodos de una clase de test de forma sencilla. Entiendo que mirándolo de una forma purista cada uno de los métodos de un test case debe ser independiente y su ejecución no se debería ver afectada por el resto, pero en determinados casos es de mucha ayuda poder marcar el orden de ejecución, como por ejemplo poder probar la conexión a una fuente de datos antes de obtener los datos.
En este articulo se pretende exponer diferentes alternativas para dar respuesta a este caso de uso.
Error NullPointerException al evaluar una expresión ternaria
12-02-2016 - Antonio Archilla
Descripción de error
Se produce un error de tipo NullPointerException al evaluar una expresión ternaria donde se mezclan valores de tipo primitivo (int, long, double…) con sus correspondientes tipos Wrapper (Integer, Long, Double) si el valor de resultante de la expresión es null.
Cuando la expresión condicional evalua y se asigna un valor no nulo, en este caso el segundo operando de la expresión, la operación funciona correctamente:
long val1 = 1;
Long valor2 = val1==1 ? val1 : (Long)null;
System.out.println("VALOR2 is null -> " + (valor2 != null));
→ VALOR2 is null -> true
En cambio, cuando se evalúa la condición y el valor resultante es null, tercer operando en el ejemplo, aunque este último se trate como un tipo objeto, se produce un error:
long val1 = 2;
Long valor2 = val1==1 ? val1 : (Long)null;
System.out.println("VALOR2 is null -> " + (valor2 != null));
→ Exception in thread "main" java.lang.NullPointerException
Solución propuesta
El error se produce porque en las expresiones ternarias de este tipo, el compilador escoge como tipo de retorno el valor primitivo, en el caso de los ejemplos anteriores el tipo long en lugar del tipo wrapper Long. Por esta razón, aunque se especifique una conversión explicita al tipo adecuado cuando se utiliza un valor nulo, siempre se producirá un error si ese es el resultado de la operación ya que el tipo primitivo no admite este tipo de valores.
La solución simple a este error es trasformar en todos los casos el valor resultante a un tipo wrapper. En el ejemplo, el segundo miembro de la operación es transformado a Long mediante el método valueOf para que todos los operandos sean de este tipo, que si admite valores nulos. El compilador escogerá este tipo para el resultado de la operación ya que es el único presente en las 2 alternativas, tanto si se cumple la condición como si no.
long val1 = 2;
Long valor2 = val1==1 ? Long.valueOf(val1) : (Long)null;
System.out.println("VALOR2 is null -> " + (valor2 != null));
→ VALOR2 is null -> false
Referencias
Error al tratar un dato de tipo CLOB con Hibernate en una base de datos PostgreSQL
31-01-2016 - Antonio Archilla
Descripción de error
Se produce un error al recuperar datos de tipo LOB de una entidad a través de la capa de persistencia basada en JPA + Hibernate si la base de datos subyacente es PostgreSQL. Se produce un error de tipo:
org.postgresql.util.PSQLException: Bad value for type long
Patrón Cadena de Responsabilidad con Spring
07-12-2015 - Antonio Archilla
El patrón de diseño Cadena de Responsabilidad (Chain of Responsability) es un patrón de tipo «comportamiento», es decir, que establece protocolos de interacción entre clases y objetos emisores y receptores de los mensajes a procesar. Es usado para desacoplar las diferentes implementaciones de un algoritmo de su uso final, ya que el emisor del mensaje no tiene porqué conocer el componente que finalmente procesará el mensaje.
Su funcionamiento básico es el siguiente:
- Se forma una lista encadenada con todos los posibles receptores del mensaje, de forma que cada uno de ellos tengo un enlace al siguiente, si se quiere, ordenados pueden ordenarse por prioridad de forma que en caso de que varios de ellos sean capaces de procesar un mismo mensaje, prevalezca el que tenga una prioridad mas alta según criterios funcionales.
- El emisor del mensaje, sólo ha de tener acceso al primero de los receptores. Será a este al que se le hará la llamada inicia y quien proporcionará el resultado al emisor.
- Cada uno de los receptores, evaluará el mensaje proporcionado por el emisor y decidirá si es capaz de procesarlo y proporcionar un resultado. En caso afirmativo, se acabará la cadena de llamadas a posteriores receptores y se retornará. Esto hará que el resultado pase por todos los receptores ejecutados anteriormente hasta devolvérselo al emisor. En caso que el receptor actual no sea capaz de evaluar el mensaje, delegará en el siguiente receptor en la cadena esperando el resultado que le proporcione, sea el o no el que finalmente se haga cargo de proporcionárselo.Todo lo explicado hasta ahora se puede resumir en el siguiente diagrama de secuencia: