La lliçó anterior va acabar amb una ironia: BiblioTech té un @Transactional sobre prestar que no fa absolutament res, perquè a sota no hi ha cap base de dades que pugui confirmar o revertir. Tota la persistència continua sent el que era al mòdul 7: fitxers CSV escrits a mà.

Aquesta lliçó els substitueix per una base de dades relacional de veritat.

Hibernate és l'ORM més usat del món Java, i la implementació de referència de Jakarta Persistence (abans JPA). La seva feina és traduir entre dos móns que no encaixen: el dels objectes, amb herència, referències i navegació; i el de les taules, amb files, columnes i claus foranes. Aquesta feina és tediosa, repetitiva i fàcil de fer malament, i per això existeix una eina per automatitzar-la.

Però un ORM no és una capa transparent que es pugui fer servir sense entendre-la. És probablement la peça de la qual més gent abusa sense saber què està passant: consultes que es multipliquen per cent, excepcions que apareixen fora de la transacció, entitats que es desen soles sense que ningú cridi save, i esquemes de producció destruïts per una propietat mal posada. Tot això té explicació, i aquesta lliçó la dóna.

L'avantatge amb què arribes és el de sempre: Hibernate llegeix @Entity i @Column per reflexió, exactament igual que el teu ExportadorAnotat llegia @CampCsv. I Spring Data JPA et donarà repositoris funcionant sense escriure la implementació, amb el mateix Proxy.newProxyInstance de 10-03.

En acabar sabràs què automatitza un ORM i què costa; mapejaràs entitats i relacions completes; entendràs el context de persistència i els estats d'una entitat; sabràs per què apareix la LazyInitializationException i què és el problema N+1, amb les seves solucions; escriuràs consultes JPQL amb paràmetres —i sabràs per què concatenar cadenes és una vulnerabilitat—; manejaràs transaccions, propagació i bloqueig optimista; i BiblioTech desarà les seves dades a H2 amb Material, Empleat i Prestec com a entitats reals.

1. El desajust objecte-relacional
2. Què es guanya i què es perd enfront de JDBC
3. JDBC en vint línies: la línia base
4. JPA enfront d'Hibernate: especificació i implementació
5. Posar en marxa JPA amb H2 a BiblioTech
6. La primera entitat: @Entity, @Table, @Id
7. @GeneratedValue i les seves estratègies
8. @Column i el mapatge de tipus
9. @Enumerated: per què STRING i mai ORDINAL
10. LocalDate, Instant i els conversors propis
11. @Embeddable i @Embedded
12. Relacions: els quatre tipus
13. Costat propietari i mappedBy
14. FetchType: càrrega mandrosa enfront d'ansiosa
15. La LazyInitializationException
16. El problema N+1
17. Resoldre'l: JOIN FETCH i @EntityGraph
18. CascadeType i orphanRemoval
19. El context de persistència i l'EntityManager
20. Els quatre estats d'una entitat
21. La comprovació de canvis automàtica
22. flush i l'ordre de les operacions
23. Les operacions: persist, merge, find, getReference, remove
24. Consultes: JPQL
25. Consultes amb nom, API de criteris i SQL natiu
26. Injecció SQL: per què mai no es concatena
27. Transaccions: @Transactional amb base de dades real
28. Propagació i aïllament
29. Bloqueig optimista amb @Version
30. Memòries cau de primer i segon nivell
31. ddl-auto i per què mai update en producció
32. Spring Data JPA
33. BiblioTech: de CSV a H2
34. Errors comuns i consells
35. Exercicis

El problema té nom propi: desajust d'impedància objecte-relacional (object-relational impedance mismatch). El model d'objectes i el model relacional es van inventar per a coses diferents i no encaixen de forma natural.

Els punts de fricció concrets:

Fixa't en la fila de l'herència, perquè és la més brutal: el model relacional no té herència. La jerarquia segellada Material de BiblioTech, que a 10-06 permetia switch exhaustius verificats pel compilador, senzillament no es pot expressar en SQL. Algú ha de decidir com es representa, i hi ha tres estratègies diferents, cadascuna amb els seus compromisos.

I la de la navegació és la que més problemes de rendiment causa: en Java, prestec.material().editorial() és gratis; en SQL, cada salt pot ser una consulta. D'aquí surt el problema N+1 de l'apartat 16.

Un ORM (Object-Relational Mapper) és una eina que tradueix automàticament entre els dos móns. No elimina el desajust: el gestiona. I saber que existeix és la diferència entre fer servir Hibernate bé i patir-lo.

Amb honestedat, perquè hi ha opinions fortes en tots dos sentits i totes dues tenen raó en part.

La regla professional raonable:

• ORM per al CRUD del domini, que és el 80 % del codi d'una aplicació de gestió: desar un préstec, carregar un empleat, actualitzar un material.
• SQL directe (JDBC, JdbcTemplate o jOOQ) per a informes, agregacions complexes i processos massius.

Totes dues coses conviuen perfectament al mateix projecte, i això és el que fa BiblioTech.

Per entendre què automatitza Hibernate, primer cal veure què calia escriure. Això és JDBC pur llegint préstecs:

El que hi ha aquí, i el que Hibernate eliminarà:

1. SQL escrit a mà per a cada consulta.
2. Mapatge columna a columna, amb getLong, getString, getDate.
3. Conversió de tipus: java.sql.Date a LocalDate, null a Optional.empty().
4. Gestió de recursos: tres try-with-resources imbricats.
5. Traducció d'excepcions: SQLException a la jerarquia del mòdul 6.
6. Noms de columna com a cadenes: "data_venciment" mal escrit falla en execució.

Multiplica això per les quaranta consultes d'una aplicació real i per les sis entitats, i tindràs uns quants milers de línies que no aporten valor i que cal mantenir cada vegada que canvia una columna.

JDBC no és dolent. És de baix nivell. Amb Hibernate, aquesta consulta sencera es converteix en:

I ni tan sols cal escriure aquesta línia, com veuràs a l'apartat 32.

Una altra confusió clàssica que convé aclarir.

Jakarta Persistence (JPA) és una especificació: un conjunt d'interfícies i anotacions estandarditzades, al paquet jakarta.persistence. Defineix EntityManager, @Entity, @Id, @OneToMany, JPQL... però no conté codi que funcioni.

Hibernate és una implementació d'aquesta especificació. És qui de veritat genera el SQL, gestiona el context de persistència i parla amb la base de dades.

La recomanació pràctica: programa contra JPA sempre que puguis i fes servir extensions d'Hibernate només quan ho necessitis de veritat. És el mateix principi de la façana que veuràs amb SLF4J a 11-07.

Avís de versions, important. Jakarta EE va reanomenar tots els paquets javax.* a jakarta.*. Spring Boot 3 i Hibernate 6 fan servir jakarta.persistence. Si copies un exemple amb import javax.persistence.Entity, és de Spring Boot 2 o anterior i no compilarà. És l'error de copia i enganxa més freqüent avui.

Dues dependències afegides al pom.xml d'11-02:

I la configuració a application.yml:

Amb això ja està. Executa:

I a l'arrencada veuràs les condicions de l'apartat 19 d'11-02 complint-se: DataSourceAutoConfiguration detecta H2 al classpath, veu que tu no has definit un DataSource, i el crea. HibernateJpaAutoConfiguration detecta Hibernate i munta l'EntityManagerFactory i el gestor de transaccions. Zero codi de configuració.

Dues notes sobre show-sql: és imprescindible mentre aprens —veuràs exactament quin SQL genera Hibernate i això és la meitat de l'aprenentatge— i cal desactivar-lo en producció, on el logging correcte és per SLF4J (11-07):

Convertim Llibre de BiblioTech en una entitat:

Els requisits que imposa JPA a una entitat, i que convé conèixer perquè els errors són críptics:

I aquí tens per què un record no pot ser una entitat JPA: és final, els seus camps són final i no té constructor sense arguments. Els record de BiblioTech (Fitxa, ResumSessio) continuaran sent perfectes com a DTO i com a projeccions de consulta, però les entitats han de ser classes mutables. És un compromís real de l'ORM, no un caprici.

Sobre @Table: si no la poses, la taula s'anomena com la classe. Posar-la explícitament és bona pràctica, perquè Prestec mapejaria a una taula PRESTEC, i paraules com ORDER, USER o GROUP són reservades en SQL i donen errors desconcertants.

Qui genera la clau primària. És una decisió amb impacte real en el rendiment.

La recomanació amb Hibernate 6 i una base de dades que admeti seqüències:

El motiu de l'allocationSize importa: amb IDENTITY, Hibernate no pot agrupar insercions, perquè necessita executar cada INSERT perquè el motor li retorni l'id. Amb SEQUENCE i allocationSize=50, pot acumular 50 insercions i enviar-les en un lot. En una importació de 10.000 materials, la diferència és de minuts.

Per als exemples amb H2 d'aquesta lliçó farem servir IDENTITY per simplicitat, però coneix la raó per la qual en producció es prefereix SEQUENCE.

@Column descriu la columna. Els seus atributs útils:

Els tipus que JPA mapeja automàticament:

Dos avisos concrets sobre BiblioTech:

Un: mai double per a diners. Ja es va dir a 01-04 i aquí importa més que mai. Les multes són BigDecimal amb precision i scale explícits:

Dos: Optional no es mapeja. Optional<LocalDate> dataDevolucio era una decisió excel·lent a 10-04 per a l'API pública, però JPA no sap persistir Optional. La solució és un camp anul·lable i un getter que retorni Optional:

Així conserves la garantia de 10-04 —qui cridi mai no rep null— i JPA pot persistir el camp. És el patró estàndard.

BiblioTech té tres enums des del mòdul 4: Gravetat, TipusMaterial i EstatPrestec. El seu mapatge té un parany amb conseqüències greus.

Per què ORDINAL és perillós. Amb ell, la base de dades desa 0, 1, 2. Ara imagina que d'aquí a sis mesos algú afegeix un estat al seu lloc lògic:

Tots els préstecs que estaven desats amb 1 (VENCUT) passen a llegir-se com a RENOVAT, i els 2 (RETORNAT) com a VENCUT. Totes les dades històriques queden corrompudes silenciosament. Cap excepció, cap avís. Es descobreix setmanes després, quan algú reclama una multa d'un llibre que va retornar.

A més, ORDINAL fa la base de dades il·legible: SELECT * FROM prestecs retorna números que no signifiquen res.

La regla és absoluta: @Enumerated(EnumType.STRING), sempre. L'estalvi d'espai d'ORDINAL no compensa ni de bon tros el risc. I el més perillós és que ORDINAL és el valor per defecte: si oblides l'anotació, tens el comportament dolent.

Bones notícies: des de JPA 2.2, java.time es mapeja de forma nativa. Tota la feina de 10-05 es trasllada directament:

La distinció de 10-05 continua sent la correcta: LocalDate per a dates de negoci (un préstec venç "el dia 20", sense hora ni zona) i Instant per a marques de temps d'auditoria (un instant absolut a la línia temporal).

I java.util.Date i Calendar no es fan servir mai més. Si veus @Temporal(TemporalType.DATE) en un exemple, és codi anterior a Java 8.

I si vols persistir un tipus que JPA no coneix? Aquí entra AttributeConverter. BiblioTech té un record Isbn com a objecte de valor:

El conversor:

Amb autoApply = true, qualsevol camp Isbn es converteix sol. Sense ell, cal marcar-lo:

Això permet tenir objectes de valor amb validació al domini i columnes simples a la base de dades: el millor dels dos móns. Altres usos habituals: xifrar un camp sensible, desar una llista curta com a cadena separada per comes, o mapejar un booleà a 'S'/'N' en una base de dades heretada.

Un incrustable és un objecte que no té identitat pròpia i els camps del qual es desen a la mateixa fila que l'entitat que el conté. Serveix per donar estructura al model d'objectes sense crear taules.

Ús:

La taula resultant té columnes editorial, any, idioma, editorial_original, any_original... a la mateixa fila de materials. No hi ha taula dades_publicacio ni JOIN.

És la resposta al problema de granularitat de l'apartat 1: pots tenir objectes petits i cohesius en Java sense fragmentar l'esquema.

El model de BiblioTech:

• Un Prestec pertany a un Material i a un Empleat.
• Un Material té molts Prestec.
• Un Empleat té molts Prestec i moltes Reserva.
• Un Material té moltes Categoria i una Categoria té molts Material.

La taula prestecs tindrà columnes material_id i empleat_id amb claus foranes.

Aquests mètodes de conveniència no són opcionals a la pràctica: si afegeixes a la llista sense posar el camp de l'altre costat, la relació no es persisteix (apartat 13) i a més l'estat en memòria queda incoherent.

Parany conegut: un @OneToOne opcional al costat invers no pot ser mandrós amb proxies, perquè Hibernate necessita consultar per saber si hi ha fila o no. Si el rendiment importa, posa-hi optional = false o fes servir una clau primària compartida.

Consell professional molt repetit: @ManyToMany pur es queda curt gairebé sempre. Tan bon punt necessitis un atribut a la relació —data en què es va assignar la categoria, qui la va assignar— cal convertir-la en una entitat intermèdia amb dos @ManyToOne. Molts equips modelen directament l'entitat intermèdia des del principi.

Resum:

Aquest és un concepte que confon gairebé tothom i que provoca el bug de "he desat i no s'ha desat res".

En una base de dades relacional, la relació és una sola columna: la clau forana. En Java, la relació bidireccional són dos camps. Algú ha de decidir quin dels dos mana.

El costat propietari és el que té la clau forana. És l'únic que Hibernate mira per persistir la relació. L'altre costat porta mappedBy i és de només lectura a efectes de persistència.

La conseqüència:

La regla pràctica: sempre que tinguis una relació bidireccional, escriu mètodes de conveniència que actualitzin els dos costats. Mai manipulis les col·leccions directament des de fora.

Quan carregues un Prestec, ha de carregar Hibernate també el seu Material i el seu Empleat? Aquesta decisió és FetchType, i és la decisió amb més impacte en el rendiment de tota la lliçó.

Els valors per defecte de JPA són, desafortunadament, incoherents:

Per què l'EAGER per defecte de @ManyToOne és dolent: imagina que Prestec té @ManyToOne ansiosos a Material i Empleat, i que Material té un @ManyToOne ansiós a Editorial, que en té un altre a Pais. Carregar un préstec arrossega cinc taules. I aquest cost el pagues sempre, fins i tot quan només volies la data de venciment.

Regla professional: posa fetch = FetchType.LAZY explícitament a TOTES les associacions. I quan necessitis les dades relacionades, demana-les explícitament a la consulta amb JOIN FETCH o @EntityGraph.

Com funciona un proxy mandrós, i aquí torna el mòdul 10: quan carregues un Prestec, Hibernate no posa un Material al camp. Posa un objecte d'una subclasse generada de Material que no té dades, només l'id. La primera vegada que crides material.getTitol(), aquesta subclasse intercepta la crida, llança el SELECT i retorna el valor.

És el teu proxy dinàmic de 10-03 un altre cop, i d'aquí surten dues conseqüències que ja coneixes:

• Una entitat no pot ser final: no es podria generar la subclasse.
• En depurar veuràs objectes anomenats Material$HibernateProxy$xYz123. És el teu material, sense carregar.

La contrapartida de la càrrega mandrosa, i una de les excepcions més famoses del món Java.

Què ha passat, pas a pas:

1. Dins de la transacció, Hibernate va carregar el préstec i va posar un proxy al camp material.
2. La transacció va acabar i el context de persistència es va tancar.
3. En cridar getTitol(), el proxy intenta llançar el SELECT... i ja no hi ha sessió amb la qual fer-ho.

Les solucions, de millor a pitjor:

1. Portar el que necessites a la consulta (la correcta):

2. Retornar un DTO en comptes de l'entitat (la millor arquitectònicament):

Aquesta FitxaPrestec pot ser perfectament un record — on sí que encaixen de meravella.

3. Ampliar la transacció fins a cobrir l'ús: solució vàlida de vegades, però mantenir transaccions obertes més temps del necessari té el seu propi cost.

4. spring.jpa.open-in-view=true: desaconsellada, encara que és el valor per defecte de Spring Boot. Manté el context de persistència obert durant tota la petició HTTP, de manera que l'excepció no apareix mai... i a canvi amaga el problema N+1, manté connexions ocupades més temps i provoca consultes des de la capa de presentació. Per això a l'application.yml de l'apartat 5 apareix explícitament:

Consell: mantenir-lo a false fa que la LazyInitializationException aparegui a la teva màquina en comptes que el problema de rendiment aparegui en producció.

El problema de rendiment número u dels ORM. I és tan fàcil de provocar que gairebé tothom el té sense saber-ho.

Amb 500 préstecs, el log de show-sql mostra:

501 consultes on n'hi hauria d'haver una. Amb 2 ms de latència per consulta, un segon sencer perdut. I si hi afegeixes l'empleat, en són 1001.

L'insidiós de l'assumpte: en desenvolupament, amb 5 préstecs de prova, és instantani. El problema apareix en producció amb dades reals, i per llavors la causa és en un bucle que sembla inofensiu.

Nota important: canviar a EAGER no ho arregla. Amb EAGER, Hibernate carrega les associacions sempre, però moltes vegades ho fa igualment amb una consulta per entitat. L'únic que aconsegueixes és tenir el problema sempre, fins i tot quan no anaves a fer servir els materials.

Com detectar-lo:

1. spring.jpa.show-sql=true i comptar les consultes al log.
2. Estadístiques d'Hibernate: spring.jpa.properties.hibernate.generate_statistics=true.
3. En producció: mètriques i traces distribuïdes (12-07).

Dues solucions, totes dues de l'especificació.

Ara es genera una sola consulta:

De 501 consultes a 1.

Compte amb un detall: JOIN FETCH sobre una col·lecció pot duplicar files. Si portes un empleat amb els seus 5 préstecs, el JOIN retorna 5 files i podries obtenir l'empleat repetit. Es resol amb SELECT DISTINCT o demanant un Set. I una limitació coneguda: no es pot paginar un JOIN FETCH de col·lecció de forma eficient; Hibernate avisa que està paginant en memòria. En aquest cas, la solució és portar els ids paginats en una consulta i les entitats completes en una altra.

Avantatge: el mateix mètode pot tenir diversos grafs, i no cal escriure JPQL.

La projecció a DTO mereix menció a part perquè és la solució més eficient per a informes:

Una consulta, només quatre columnes, sense entitats gestionades i sense risc d'N+1. I FitxaPrestec és un record — que per fi troba el seu lloc a la capa de persistència.

Les cascades propaguen operacions del pare als fills.

orphanRemoval = true significa: si treus un fill de la col·lecció, esborra'l de la base de dades.

Diferència amb CascadeType.REMOVE:

Avís seriós: CascadeType.ALL sobre relacions on el fill té vida pròpia és una font de pèrdua de dades. Si Material tingués cascade = ALL sobre els seus préstecs, donar de baixa un llibre esborraria tot el seu historial de préstecs, amb les seves multes i la seva auditoria. Fes servir cascades només quan la relació sigui de composició real (el fill no existeix sense el pare).

Aquí hi ha el cor conceptual de JPA, i el que separa qui entén Hibernate de qui el pateix.

L'EntityManager és la porta d'entrada a JPA. I gestiona un context de persistència: una memòria cau d'entitats on cada entitat carregada o desada queda gestionada mentre duri la transacció.

Tres propietats del context de persistència, totes amb conseqüències:

1. És una memòria cau de primer nivell. Si demanes dues vegades la mateixa entitat a la mateixa transacció, la segona no genera consulta.
2. Garanteix identitat. Dins d'una transacció, la mateixa fila és sempre el mateix objecte Java: a == b és true. Això resol el problema d'identitat de l'apartat 1.
3. Detecta canvis automàticament. És l'apartat 21, i és el que més sorprèn.

A Spring, l'EntityManager s'injecta així:

Aquest EntityManager injectat no és una instància real: és un proxy que a cada crida busca el context de persistència associat a la transacció del fil actual. Un altre cop el mateix mecanisme del mòdul 10.

Tota entitat és en un de quatre estats, i saber en quin és la clau per entendre què farà Hibernate.

L'exemple que ho aclareix tot:

I l'error clàssic que produeix:

Perquè un canvi sobre una entitat separada es desi, cal reincorporar-la amb merge (apartat 23).

Això és el que més sorprèn de JPA, i alhora el més potent.

Com? El mecanisme s'anomena dirty checking i funciona així:

1. En carregar l'entitat, Hibernate desa una instantània de l'estat de tots els seus camps.
2. En fer flush (normalment en confirmar), compara l'estat actual amb la instantània.
3. Per a cada camp diferent, genera l'UPDATE corresponent.

Conseqüències pràctiques, totes importants:

Una: no cal cridar save sobre entitats gestionades. Moltíssim codi Spring Data crida save() innecessàriament. No fa mal, però és soroll.

Dues: qualsevol modificació accidental es persisteix. Si dins d'una transacció toques un camp d'una entitat gestionada "només per calcular alguna cosa", aquest canvi va a la base de dades. És una font real de bugs desconcertants.

Tres: readOnly = true la desactiva i estalvia feina.

En consultes que retornen moltes entitats, la diferència és mesurable. És un bon costum marcar readOnly = true a tots els mètodes de només lectura.

Quatre: el cost creix amb el nombre d'entitats gestionades. Carregar 100.000 entitats en una transacció fa que cada flush compari 100.000 instantànies. Per a processos massius cal netejar el context periòdicament amb entityManager.clear().

flush és el moment en què Hibernate escriu realment el SQL pendent a la base de dades. No és el mateix que commit.

Quan passa automàticament:

1. En confirmar la transacció (sempre).
2. Abans d'executar una consulta que es pogués veure afectada pels canvis pendents.
3. Quan crides entityManager.flush() explícitament.

I aquí ve un detall que sorprèn: Hibernate no executa el SQL en l'ordre en què tu crides els mètodes. Reordena les operacions així:

1. INSERT d'entitats, en ordre de persist
2. UPDATE
3. Esborrat d'elements de col·leccions
4. Inserció d'elements de col·leccions
5. DELETE d'entitats

Per això aquest codi pot fallar de forma incomprensible:

La solució és forçar l'ordre:

Entendre que existeix un "SQL pendent" que s'executa més tard i reordenat explica la meitat dels comportaments estranys d'Hibernate.

La regla: fes servir sempre l'objecte que retorna merge. Ignorar el valor de retorn és un error freqüentíssim.

L'únic que necessita l'INSERT és el material_id, i getReference el té. Estalvies un SELECT per operació. La contrapartida: si accedeixes a qualsevol propietat del proxy fora de la sessió, tindràs una LazyInitializationException, i si l'id no existeix, l'error arriba tard (EntityNotFoundException en accedir-hi, no en demanar la referència).

JPQL (Jakarta Persistence Query Language) sembla SQL però opera sobre entitats i els seus atributs Java, no sobre taules i columnes.

Exemples complets sobre BiblioTech:

Avís sobre aquesta última: les consultes de modificació massiva s'executen directament a la base de dades i no actualitzen les entitats ja carregades al context de persistència, que queden desincronitzades. Després d'una així, convé em.clear().

Diferències clau amb SQL:

Es declaren a l'entitat i es validen en arrencar, no en executar-se:

Avantatge real: un error de sintaxi al JPQL impedeix arrencar l'aplicació, en comptes d'esclatar el dia que algú invoqui aquest informe.

Per a consultes construïdes dinàmicament —un cercador amb cinc filtres opcionals—, concatenar JPQL a mà és lleig i perillós. JPA ofereix una API amb tipus:

És verbosa, i per això molta gent prefereix les Specification de Spring Data o QueryDSL. S'esmenta perquè sàpigues que existeix i per a què serveix; a la pràctica es fa servir poc.

Quan necessites una funció específica del motor, una consulta molt optimitzada o un informe complex:

És perfectament legítim. Un ORM no obliga a fer-ho tot amb ell, i pretendre el contrari porta a JPQL recargolats que ningú entén. L'única pèrdua és la portabilitat entre motors.

Això no és una recomanació d'estil. És una vulnerabilitat de seguretat.

Si correu ve d'un formulari o d'un paràmetre d'una API, un atacant pot enviar:

I la consulta es converteix en:

que retorna tots els préstecs de tots els empleats. Amb SQL natiu, les conseqüències són pitjors: depenent del motor i dels permisos, es pot arribar a llegir altres taules o modificar dades.

La solució és sempre la mateixa, i és trivial:

Amb paràmetres, el valor mai no s'interpreta com a part de la consulta: viatja a part i es tracta com una dada literal, passi el que passi a dins. És la mateixa raó per la qual l'exemple de JDBC de l'apartat 3 feia servir PreparedStatement amb ? i setString.

La regla, sense excepcions: tot valor que vingui de fora va com a paràmetre. Ni tan sols "quan sé que és un número" —perquè demà aquest codi es copia a un altre lloc on no ho és.

L'únic que no es pot parametritzar són els noms de taula i columna i el sentit d'un ORDER BY. Si necessites que siguin dinàmics, valida'ls contra una llista blanca de valors permesos, mai els concatenis tal qual.

La seguretat d'aplicacions —validació d'entrada, autorització, gestió de secrets, capçaleres— es tracta a 12-07. Aquí n'hi ha prou amb la regla: paràmetres sempre.

Ara que hi ha base de dades, el @Transactional d'11-02 fa alguna cosa.

Una transacció compleix les propietats ACID:

El cas de BiblioTech:

Si registreAuditoria.anotar falla, es reverteix tot: l'exemplar torna a estar disponible i no queda cap préstec orfe. Sense transacció, quedaria un exemplar menys i un préstec sense auditar, i ningú sabria per què.

Recorda les dues regles d'11-02, que continuen valent aquí: rollback només davant d'excepcions no comprovades per defecte, i les crides internes no passen pel proxy.

El cas on REQUIRES_NEW és la resposta correcta:

Compte: REQUIRES_NEW consumeix una segona connexió del pool mentre la primera continua oberta. Abusar-ne esgota el pool i provoca interbloquejos. Fes-lo servir només quan la independència sigui un requisit real.

Els tres fenòmens, amb BiblioTech:

• Lectura bruta: llegeixes un exemplar com a prestat i aquesta transacció es reverteix. Vas llegir una cosa que mai no va existir.
• Lectura no repetible: llegeixes exemplars_disponibles = 1, un altre presta, tornes a llegir i hi ha 0. Dues lectures, dos resultats.
• Lectura fantasma: comptes 3 préstecs actius, un altre n'insereix un, repeteixes la consulta i n'hi ha 4.

A la pràctica, gairebé mai no es toca l'aïllament. READ_COMMITTED amb bloqueig optimista (apartat següent) resol el 99 % dels casos amb molt menys cost que pujar el nivell.

El cas concret, que reprèn directament el mòdul 8:

Marta Ruiz i Diego Alonso obren alhora la fitxa de "Java Eficaç", que té 1 exemplar disponible. Tots dos premen "Prestar" al mateix segon.

És exactament la condició de cursa de 08-04, però distribuïda: aquí synchronized no serveix de res, perquè els dos usuaris poden estar en instàncies diferents de l'aplicació.

Dues estratègies:

El bloqueig optimista és una sola anotació:

Amb això, cada UPDATE inclou la versió llegida a la condició:

Si un altre ja va actualitzar, la fila té version=6 i la condició no troba cap fila. Hibernate ho detecta i llança:

Gestionar-ho bé:

Aquest Resultat<T> és el tipus genèric que vas escriure a 10-01, i aquí encaixa perfectament. I aquest bucle de reintents és, conceptualment, el teu ProxyReintents de 10-03: en un projecte real el declararies amb @Retryable de Spring Retry.

Bloqueig pessimista, quan l'operació és cara i el conflicte probable:

Genera SELECT ... FOR UPDATE: el segon espera el primer. Correcte, però amb cost real de concurrència.

La de primer nivell ja la coneixes: és el context de persistència de l'apartat 19. No es pot desactivar i és la que garanteix la identitat d'objectes.

La de segon nivell és opcional i compartida per totes les transaccions. Necessita un proveïdor (Ehcache, Caffeine, Hazelcast):

Quan activar-la: dades que es llegeixen molt i canvien poc. El catàleg de materials o les categories de BiblioTech són bons candidats; els préstecs, no.

Advertiments que cal tenir presents:

1. Coherència: si una altra aplicació modifica la base de dades, la teva memòria cau queda obsoleta i serveix dades velles.
2. En clúster: amb diverses instàncies, cadascuna té la seva memòria cau. O fas servir una memòria cau distribuïda o tindràs incoherències.
3. Mesura abans: activar la memòria cau de segon nivell "per si de cas" afegeix complexitat sense benefici demostrat. És exactament el que deia 10-07: mesurar abans d'optimitzar.

Hibernate pot generar l'esquema a partir de les teves entitats. És còmode i perillós.

Per què update no es fa servir mai en producció, amb motius concrets:

1. Mai no esborra res. Si treus un camp, la columna es queda allà per sempre. Si reanomenes titol a nom, afegeix nom i deixa titol — i no copia les dades.
2. No versiona res. No hi ha registre de quins canvis es van aplicar ni quan, i no hi ha manera de desfer-los.
3. És impredictible. El SQL que genera depèn del dialecte, de la versió d'Hibernate i de l'estat actual de l'esquema.
4. No es pot revisar abans. Ningú ha vist l'ALTER TABLE que s'executarà contra la base de dades de producció.
5. No pot fer migracions de dades. Dividir nom_complet en nom i cognoms requereix lògica que cap eina automàtica no pot inventar.

La configuració correcta per entorn:

validate és especialment valuós: si l'esquema real no coincideix amb les entitats, l'aplicació no arrenca, i això és molt millor que descobrir-ho amb un error a les tres de la matinada.

En producció, l'esquema es gestiona amb migracions versionades: fitxers SQL numerats que s'apliquen en ordre i queden registrats en una taula de control.

Avantatges: el canvi d'esquema està a git, és revisable, és reproduïble i es pot provar abans. Es desenvolupa a 12-06, juntament amb el desplegament.

Última peça, i la que més codi elimina.

Amb JPA pur, un repositori són unes vuitanta línies. Amb Spring Data JPA:

Això ja et dóna save, findById, findAll, deleteById, count, existsById, paginació i ordenació.

Spring Data analitza el nom del mètode i genera la consulta. Les paraules clau habituals:

Consell pràctic: els noms derivats són fantàstics fins que deixen de ser-ho. findByDataVencimentBeforeAndDataDevolucioIsNullAndEstatNot és il·legible. Quan el nom passi de tres condicions, fes servir @Query.

Si no necessites el total, Slice<T> evita el COUNT i és més ràpid.

PrestecRepository és una interfície sense implementació. Qui executa findByEstat?

A l'arrencada, Spring Data:

1. Escaneja les interfícies que estenen Repository.
2. Per a cadascuna, crea una implementació al vol amb Proxy.newProxyInstance — el mateix de 10-03.
3. L'InvocationHandler rep cada crida, mira si el mètode té @Query (i fa servir aquest JPQL) o analitza el seu nom (i genera el JPQL), l'executa amb l'EntityManager i adapta el resultat.

És literalment el que vas escriure a 10-03: un proxy sobre una interfície que interpreta les metadades del mètode i actua. La diferència és la sofisticació de l'anàlisi, no el mecanisme.

I hi ha una conseqüència pràctica: el repositori es pot substituir per un simulat a les proves sense cap dificultat, perquè és una interfície. És exactament el que farà 11-06.

El resultat complet de la migració.

Aquí es paga un dels preus reals de l'ORM, i cal dir-ho amb claredat: la jerarquia sealed de 10-06 desapareix. Una entitat JPA no pot ser sealed ni record ni final. Es perden els switch exhaustius verificats pel compilador i cal substituir-los per polimorfisme o per comprovacions amb instanceof. És un compromís conscient: es guanya persistència real, consultes i integritat; es perd part de l'expressivitat del model de tipus. Un disseny alternatiu —i freqüent en projectes que valoren molt el domini— manté el domini pur i fa servir entitats JPA separades amb un mapatge entre tots dos. Aquesta discussió pertany a 12-02.

Les tres estratègies d'herència, perquè sàpigues què vas triar:

Els repositoris:

Dades inicials per a desenvolupament, a src/main/resources/data.sql:

Execució:

L'abans i el després:

Error: javax.persistence en comptes de jakarta.persistence. L'error de copia i enganxa número u avui. Spring Boot 3 i Hibernate 6 fan servir jakarta.

Error: deixar @Enumerated per defecte (ORDINAL). Reordenar un enum corromp silenciosament totes les dades històriques. Sempre EnumType.STRING.

Error: deixar @ManyToOne en EAGER. És el valor per defecte i és dolent. Posa LAZY explícitament a totes les associacions i porta el que necessitis amb JOIN FETCH.

Error: el problema N+1 sense adonar-se'n. Un bucle sobre entitats accedint a una relació mandrosa. Activa show-sql en desenvolupament i compta les consultes.

Error: spring.jpa.open-in-view=true. És el valor per defecte de Spring Boot i amaga l'N+1 fins a producció. Posa'l a false.

Error: modificar només el costat invers d'una relació. empleat.getPrestecs().add(p) sense p.setEmpleat(empleat) no persisteix res. Escriu mètodes de conveniència.

Error: ignorar el retorn de merge. merge(e) retorna una altra instància; l'original continua separada i els seus canvis es perden.

Error: CascadeType.ALL sense pensar-hi. Esborrar un material podria esborrar el seu historial complet de préstecs.

Error: ddl-auto=update en producció. No esborra, no versiona, no migra dades i ningú revisa el SQL que executarà. validate més Flyway.

Error: concatenar valors en una consulta. És injecció SQL. Paràmetres sempre, sense excepcions.

Error: entitats final, record o amb mètodes final. Hibernate necessita generar subclasses proxy. No compilarà el model o fallarà la càrrega mandrosa.

Error: equals i hashCode basats en l'id generat. Abans de persistir, l'id és null; després canvia, i una entitat ficada en un HashSet deixa de trobar-se. Fes servir una clau de negoci (l'isbn) o el patró recomanat d'Hibernate.

Consell: activa show-sql mentre aprens. Veure el SQL generat és la meitat de l'aprenentatge, i t'ensenya a detectar l'N+1 a l'instant.

Consell: marca readOnly = true als mètodes de consulta. Desactiva la comprovació de canvis i estalvia feina real.

Consell: fes servir DTO (record) per al que surt del servei. Retornar entitats gestionades fora de la transacció és la causa directa de la LazyInitializationException, i a més acobla la teva API interna a l'esquema.

Consell: @Version a tota entitat que es modifiqui concurrentment. Costa una anotació i evita actualitzacions perdudes.

Consell: no ho facis tot amb l'ORM. Per a informes i agregacions, SQL natiu o JdbcTemplate són millors eines. És legítim i professional.

Consell: getReference quan només necessitis la referència per assignar una FK. Estalvia un SELECT per operació.

BiblioTech té reserves: quan no hi ha exemplars, un empleat reserva i se l'avisa en retornar-se'n un. Aquest és el record del mòdul 10:

Converteix-lo en una entitat JPA que compleixi:

1. Taula reserves amb clau primària autogenerada.
2. Relacions @ManyToOne mandroses a Material i Empleat, no cadenes.
3. L'enum desat de forma segura.
4. instantAvis anul·lable a la base de dades però exposat com a Optional.
5. Bloqueig optimista.
6. Un índex sobre (material_id, estat) per a la consulta de pendents.
7. Un mètode de domini avisar(Clock rellotge) que canviï l'estat i registri l'instant, amb validació.
8. El repositori Spring Data amb: pendents d'un material ordenades per antiguitat, caducades abans d'una data, i comptar pendents d'un empleat.

Aquest servei funciona bé amb els 5 préstecs de desenvolupament i triga 9 segons en producció amb 800.

Es demana:

1. Calcula quantes consultes SQL s'executen amb 800 préstecs, desglossades.
2. Explica exactament per què.
3. Proposa tres solucions diferents amb el seu codi, indicant quantes consultes queden en cadascuna.
4. Digues quina triaries i per què.

Marta Ruiz i Diego Alonso intenten prestar simultàniament l'últim exemplar de "Refactorització" (978-0000000003, 1 exemplar).

Es demana:

1. Descriu la seqüència exacta d'esdeveniments que produeix dos préstecs amb un sol exemplar.
2. Explica per què synchronized (08-04) no resol això en un desplegament real.
3. Resol-ho amb bloqueig optimista, incloent-hi la gestió de l'excepció amb reintent.
4. Resol-ho amb bloqueig pessimista.
5. Compara'ls tots dos en una taula i recomana'n un.

Solució 1

Repositori (8):

Decisions destacables:

• record → classe: obligatori, perquè un record és final i sense constructor buit.
• Relacions en comptes de cadenes: Material i Empleat en comptes d'isbn i correuEmpleat. Dóna integritat referencial (no es pot reservar un material inexistent) i navegació. El preu és haver de gestionar la mandra.
• Optional fora, camp anul·lable dins: es conserva la garantia de 10-04 sense barallar-se amb JPA.
• El comportament viu a l'entitat: avisar, completar i haCaducat validen les transicions. L'entitat no és una bossa de dades.
• @EntityGraph a la primera consulta: se sap que es llegirà el nom de l'empleat, així que es porta d'una vegada.

Solució 2

1. Quantes consultes.

Amb 3-4 ms de latència per consulta, entre 7 i 10 segons. Coincideix amb el símptoma.

2. Per què. Les tres associacions són mandroses. La consulta inicial porta només les files de prestecs, amb proxies a material i empleat i una col·lecció mandrosa a categories. Cada accés dins del map dispara el seu propi SELECT. En desenvolupament, amb 5 préstecs, són 16 consultes i ningú ho nota.

Solució A — JOIN FETCH (1 consulta si es limita al que és escalar, 2 amb la col·lecció):

DISTINCT és necessari perquè el JOIN FETCH de la col·lecció de categories duplica files de préstec. 1 consulta. Limitació: no es pot paginar eficientment amb un JOIN FETCH de col·lecció.

Solució B — @EntityGraph (declarativa, mateix resultat):

Avantatge: no es toca el codi del servei i el mateix mètode pot tenir un altre graf en una altra consulta. 1-2 consultes.

Solució C — projecció a DTO (la més eficient):

1 consulta, i només 3 columnes en comptes de totes les de tres taules. Sense entitats gestionades, sense comprovació de canvis, sense risc d'N+1 posterior. Per a les categories caldria una consulta addicional o STRING_AGG en SQL natiu.

Comparació:

4. Quina triar. Per a un informe de només lectura, la C. Raons: porta només el necessari, no hi ha entitats gestionades ni comprovació de canvis, i —el més important— és estructuralment impossible que reaparegui l'N+1, perquè no hi ha proxies que puguin disparar-se. Amb A i B, algú que demà afegeixi un p.getMaterial().getEditorial().getPais() al format torna a tenir el problema.

Si el mètode hagués de retornar entitats per modificar-les després, la B, per ser declarativa i reutilitzable.

Solució 3

1. La seqüència.

És una actualització perduda: l'UPDATE de Diego es va calcular a partir d'un valor obsolet. Amb READ_COMMITTED, cap de les dues transaccions no veu res anòmal.

2. Per què synchronized no serveix. synchronized sincronitza fils dins d'una mateixa JVM. En un desplegament real hi ha diverses instàncies de BiblioTech darrere d'un balancejador (12-06), i Marta i Diego poden estar atesos per processos diferents, en màquines diferents. Un monitor de la JVM A no bloqueja res a la JVM B. A més, encara que hi hagués una sola instància, serialitzar tots els préstecs de tots els materials per un únic pany seria un coll d'ampolla innecessari. La coordinació ha d'estar on és la dada compartida: a la base de dades.

3. Bloqueig optimista.

Què passa ara a t8: l'UPDATE de Diego porta where id=1 and version=0, però la fila ja té version=1. Afecta 0 files, Hibernate llança OptimisticLockException i Spring la tradueix a OptimisticLockingFailureException. El reintent torna a llegir, veu disponibles=0 i retorna un error de negoci correcte.

Resultat<T> és el tipus genèric de 10-01, i el bucle de reintents és el teu ProxyReintents de 10-03 — que en un projecte real seria @Retryable(retryFor = OptimisticLockingFailureException.class, maxAttempts = 3).

4. Bloqueig pessimista.

Convé afegir un temps màxim d'espera per no bloquejar indefinidament:

5. Comparació i recomanació.

Recomanació: bloqueig optimista. A BiblioTech, la probabilitat que dues persones prestin el mateix exemplar al mateix segon és baixíssima, i el bloqueig pessimista faria pagar el cost de la serialització a les milers d'operacions que mai no xoquen. @Version costa una anotació, no penalitza el cas normal i funciona igual amb una instància que amb vint.

El bloqueig pessimista es reserva per a operacions on el conflicte sigui la norma i la feina perduda sigui cara: per exemple, un procés nocturn que recalcula totes les multes i no vol reintentar cinc mil vegades.

Els CSV de BiblioTech han desaparegut. Hi ha una base de dades de veritat a sota, i saps exactament què hi està passant.

Entens el desajust objecte-relacional que un ORM existeix per gestionar: identitat doble, herència que en SQL no existeix, navegació que en Java és gratis i en SQL costa consultes, granularitat, col·leccions i tipus. I saps què guanyes i què perds enfront de JDBC directe —que vas veure en vint línies, amb el seu mapatge columna a columna, la seva conversió de tipus i la seva gestió de recursos— amb la regla professional que se'n deriva: ORM per al CRUD del domini, SQL directe per a informes i processos massius, i tots dos convivint sense conflicte.

Distingeixes JPA d'Hibernate: especificació (jakarta.persistence) enfront d'implementació, amb la recomanació de programar contra l'especificació i l'advertiment de versions que avui causa més errors de compilació que cap altre —jakarta, mai javax.

Saps mapejar entitats: @Entity, @Table, @Id, les estratègies de @GeneratedValue amb el motiu real pel qual SEQUENCE supera IDENTITY (permet agrupar insercions), @Column amb els seus atributs, i els requisits que imposa JPA —constructor sense arguments, res final— que expliquen per què un record no pot ser una entitat. Coneixes la regla absoluta d'@Enumerated(EnumType.STRING), perquè ORDINAL és el valor per defecte i reordenar un enum corromp silenciosament totes les dades històriques. Mapeges LocalDate i Instant de forma nativa amb la mateixa distinció de 10-05, escrius conversors amb AttributeConverter per a objectes de valor com Isbn, i fas servir @Embeddable per tenir objectes petits en Java sense fragmentar l'esquema.

Modeles relacions completes amb els seus quatre tipus, saps que el costat propietari és el que té la clau forana i que tocar només el costat invers no persisteix res —d'aquí els mètodes de conveniència—, i domines la decisió que més impacte té en el rendiment: FetchType. Saps que els valors per defecte són incoherents, que @ManyToOne ve en EAGER i que la regla professional és posar LAZY explícitament a tot i demanar el que necessitis a la consulta. Coneixes les dues conseqüències: la LazyInitializationException, amb les seves quatre solucions ordenades i el consell de deixar open-in-view a false perquè el problema aparegui a la teva màquina i no en producció; i el problema N+1, que converteix una consulta en 501 i que és invisible amb cinc files de prova, amb les seves solucions —JOIN FETCH, @EntityGraph, @BatchSize i, la més eficient per a informes, la projecció a DTO, on els record troben per fi el seu lloc—. I saps que passar a EAGER no arregla res: ho empitjora.

Entens el context de persistència, que és el cor conceptual de JPA: una memòria cau de primer nivell que garanteix que la mateixa fila és el mateix objecte, amb els quatre estats d'una entitat i les seves transicions. I amb això la comprovació de canvis automàtica, que sorprèn tothom: modifiques una entitat gestionada, no crides res, i en confirmar apareix un UPDATE. Saps com funciona (instantània i comparació), les seves quatre conseqüències —inclòs que un canvi accidental es persisteix— i per què readOnly = true la desactiva i estalvia feina real. Coneixes flush, que reordena les operacions i explica la meitat dels comportaments estranys d'Hibernate, i la diferència entre persist i merge que provoca el bug d'"he ignorat el valor de retorn".

Escrius consultes: JPQL sobre entitats i atributs, consultes amb nom validades a l'arrencada, l'API de criteris per al que és dinàmic, SQL natiu quan toca, i projeccions a record en una sola línia. I tens interioritzada la regla que no admet excepcions: tot valor extern va com a paràmetre, perquè concatenar és injecció SQL —amb la llista blanca com a única sortida quan el que és dinàmic és un nom de columna—.

Manejes transaccions amb base de dades real: ACID, @Transactional amb les seves dues regles heretades d'11-02, readOnly, propagació amb el cas legítim de REQUIRES_NEW i el seu cost en connexions, i aïllament amb els tres fenòmens explicats sobre BiblioTech i el consell de gairebé mai tocar-lo. I resols el cas de l'exemplar disputat amb bloqueig optimista amb @Version, entenent per què synchronized del mòdul 8 no serveix quan hi ha diverses instàncies: la coordinació ha d'estar on és la dada compartida. Amb reintent sobre Resultat<T>, que és el teu genèric de 10-01 i el teu ProxyReintents de 10-03 fets producció.

Coneixes les memòries cau de primer i segon nivell i quan la segona val la pena —dades que es llegeixen molt i canvien poc, mesurat abans—; i saps per què ddl-auto=update no es fa servir mai en producció: no esborra, no versiona, no migra dades i ningú revisa l'ALTER TABLE que executarà. validate més migracions versionades amb Flyway, que arriben a 12-06.

I has vist Spring Data JPA convertir vuitanta línies de repositori en una interfície buida, amb mètodes derivats del nom, @Query per al que no cap en un nom, i paginació. Amb el mecanisme al descobert: Proxy.newProxyInstance sobre una interfície, exactament el de 10-03, analitzant metadades del mètode i generant la consulta.

BiblioTech té ara entitats reals, relacions amb integritat referencial, transaccions ACID, bloqueig optimista i consultes amb índexs sobre H2. Arrenca amb mvn spring-boot:run i el seu esquema es crea sol.

I continua sense tenir ni una sola prova automàtica.

Aquest és ara, amb diferència, el deute més greu. Acabes de fer una migració enorme: has canviat el model de domini, has convertit record en classes, has substituït la persistència sencera i has introduït concurrència optimista amb reintents. Com saps que el càlcul de multes continua donant el mateix resultat? Que el límit de tres préstecs per empleat es continua respectant? Que un préstec que venç en diumenge continua avisant el dilluns? L'única resposta honesta avui és: arrencant l'aplicació i mirant.

I hi ha una cosa pitjor. Aquell Clock injectable que vas introduir a 10-05, que va passar per Spring a 11-02 com un @Bean i que en aquesta lliçó ha aparegut a cada LocalDate.now(rellotge) i cada Instant.now(rellotge), existeix exclusivament per poder provar el codi sense esperar quinze dies. Porta dos mòduls esperant que algú l'aprofiti.

A la propera lliçó s'aprofita. Veuràs què és una prova automàtica i per què el cost de no tenir-ne ja l'estàs pagant; coneixeràs la piràmide de proves i JUnit 5 complet, des de @Test i el patró Preparar-Actuar-Comprovar fins a les proves parametritzades que verifiquen dotze casos del càlcul de multes en sis línies; compararàs les assercions de JUnit amb les d'AssertJ; i descobriràs què fa que un disseny sigui provable — i per què tot el que has fet als dos últims mòduls (injecció per constructor, interfícies a les fronteres, el Clock injectat, el domini lliure d'anotacions) apuntava exactament allà.

BiblioTech tindrà la seva primera xarxa de seguretat.