Los procedimientos almacenados (stored procedures) suelen ser ignorados por los programadores no especialistas en bases de datos. Pero son una herramienta con un ámbito de aplicación más que interesante y que podemos usar fácilmente con JPA sin tener que recurrir a la API JDBC. Por ello, los vemos en este pequeño capítulo que complementa el estudio del empleo de SQL con JPA e Hibernate.

Idealmente, las consultas en JPA se escriben con JPQL \ Criteria API utilizando el modelo de entidades para que sean agnósticas con respecto a la base de datos. No obstante, contamos con un magnífico soporte para la ejecución de consultas SQL, denominadas «nativas» en la especificación. ¿Por qué querríamos recurrir a él? Ya apunté algunos motivos en la introducción a los capítulos dedicados a JPA.

Completamos el estudio de los fundamentos de Criteria API con la descripción de las funciones y del bloque WHERE, incluyendo los operadores existentes y la posibilidad de efectuar subconsultas. También habrá una pequeña sección dedicada a las actualizaciones y eliminaciones.

Las consultas JPQL son simples cadenas de texto fáciles de escribir y comprender debido a sus similitudes con el lenguaje SQL. La alternativa dentro de Jakarta Persistence para explotar los datos con el modelo de entidades es la API Criteria. Permite construir consultas de forma programática, esto es, en código Java, y con un tipado absoluto tanto de los parámetros como de los resultados. Lo hace ofreciendo métodos que equivalen a las cláusulas, operadores y funciones de JPQL.

Completemos la revisión de JPQL examinando sus funciones y cómo podemos sacar partido a las nativas que ofrecen las bases de datos. No está de más subrayar que, por cuestiones de rendimiento, es preferible delegar en la base de datos todo el procesamiento y cálculo que pueda realizar, en lugar de implementarlo nosotros en el código.

Hasta ahora, nos hemos conformado con usar una única entidad en el FROM de las consultas JPQL. Para combinar datos de varias necesitamos hacer una reunión o join entre ellas, tal y como haríamos con tablas en una consulta SQL. En este capítulo examinamos los distintos tipos de reuniones disponibles.

Con los conocimientos del capítulo anterior, estamos limitados a consultas que devuelvan un único tipo de entidad o de valor escalar, pese a que ya vimos que JPQL es flexible en este aspecto. Tampoco dimos solución a la recuperación de listados grandes. Dos asuntos de vital importancia en nuestro día a día con JPA que examinamos en detalle en este capítulo.

Recién vistos los fundamentos del lenguaje de consultas JPQL, y antes de seguir profundizando, veamos cómo materializar las consultas, simples cadenas de texto, en código Java que las ejecute.

El gestor de entidades permite recuperar las entidades que conforman el modelo de datos, incluyendo relaciones entre ellas, gracias a las funciones de carga perezosa e inmediata. Pero no es suficiente. En cualquier aplicación de gestión necesitaremos explotar la información almacenada en la base de datos realizando filtros más o menos complejos, comprobando relaciones, efectuando cálculos… En definitiva, son imprescindibles las posibilidades que nos brinda el lenguaje SQL.