Data Persistence with Spring Data JPA

The in-memory repository from the previous lesson served its purpose: it let you design the API without the database dictating the shape of the responses. Now it has to be replaced with real storage, and this is where most Spring projects take on their lasting technical debt.

The difficulty isn't writing an entity — four annotations are enough — but understanding that an ORM places an intermediary between your code and the SQL that actually runs. That intermediary has rules: it tracks objects in a persistence context, it decides on its own when to write, it loads or doesn't load relationships based on implicit settings, and it only runs a transaction if the call went through the right path. A developer who ignores these rules writes code that seems to work and produces three hundred SQL queries per call, or persists nothing at all without raising a single error.

This lesson sets up persistence for biblio-api — the Livre, Auteur, and Emprunt entities — naming each pitfall as it comes up: the EAGER fetching that seems convenient, the equals that breaks collections, the @Transactional that doesn't apply.