Persistencia de datos con Spring Data JPA

El repositorio en memoria de la lección anterior cumplió su función: permitió diseñar la API sin que la base de datos dictara la forma de las respuestas. Ahora toca sustituirlo por un almacenamiento real, y es justo aquí donde la mayoría de los proyectos Spring contraen sus deudas más duraderas.

La dificultad no está en escribir una entidad (bastan cuatro anotaciones), sino en entender que un ORM coloca un intermediario entre su código y el SQL que realmente se ejecuta. Ese intermediario tiene reglas: sigue objetos dentro de un contexto de persistencia, decide por su cuenta cuándo escribe, carga o no las relaciones según ajustes implícitos y solo ejecuta una transacción si la llamada ha pasado por el camino adecuado. Un desarrollador que ignora estas reglas escribe código que parece funcionar y que genera trescientas consultas SQL por llamada, o que no persiste nada en absoluto sin lanzar el menor error.

Esta lección configura la persistencia de biblio-api (las entidades Livre, Auteur y Emprunt) y va nombrando cada trampa en el momento en que aparece: la carga EAGER que se cree práctica, el equals que rompe las colecciones, el @Transactional que no se aplica.