Persistência de dados com Spring Data JPA

O repositório em memória da lição anterior prestou um bom serviço: permitiu projetar a API sem que o banco de dados ditasse o formato das respostas. Agora é preciso substituí-lo por um armazenamento real, e é aí que a maioria dos projetos Spring contrai suas dívidas mais duradouras.

A dificuldade não está em escrever uma entidade — quatro anotações bastam — mas em entender que um ORM coloca um intermediário entre o seu código e o SQL realmente executado. Esse intermediário tem regras: ele acompanha objetos em um contexto de persistência, decide sozinho quando escrever, carrega ou não as relações de acordo com configurações implícitas, e só executa uma transação se a chamada passar pelo caminho certo. Um desenvolvedor que ignora essas regras escreve código que parece funcionar e que produz trezentas consultas SQL por chamada, ou que não persiste nada, sem lançar o menor erro.

Esta lição implementa a persistência da biblio-api — as entidades Livre, Auteur e Emprunt — nomeando cada armadilha no momento em que ela aparece: o carregamento EAGER que parece prático, o equals que quebra as coleções, o @Transactional que não se aplica.