Relations
Là où le SQL généré cesse d'être évident, et où naissent les N+1.
Relations entre entités
Une entité isolée est un exercice. Le travail réel commence quand les entités se référencent : un auteur a des livres, une commande a des lignes, un livre appartient à des catégories. C'est là que l'ORM cesse de faire ce qu'on attend, parce que Java et SQL n'expriment pas la même chose.
En Java, une association est bidirectionnelle par nature : si commande.getLignes() contient une ligne, il est naturel que ligne.getCommande() renvoie cette commande. En SQL, il n'existe qu'une seule chose : une colonne de clé étrangère, dans une seule table, d'un seul côté. La bidirectionnalité Java est une fiction que vous maintenez à la main. Quand vous oubliez de la maintenir, vous obtenez une entité dont les deux côtés se contredisent — et Hibernate écrira ce que dit le côté propriétaire, pas ce que dit votre code.
Trois familles de problèmes sortent de cette leçon, et chacune se rencontre en production. La première est le LazyInitializationException, qui surgit quand on lit une relation après la fermeture de la transaction. La deuxième est la cascade REMOVE, qui supprime plus de lignes que prévu parce qu'elle traverse tout le graphe. La troisième est le @OneToMany unidirectionnel, qui crée une table de jointure que personne n'a demandée et qui rend chaque suppression quadratique.
Commentaires
Les commentaires sont alimentés par GitHub Discussions
Connectez-vous avec GitHub pour participer à la discussion