L'une des premières choses que les nouveaux utilisateurs essaient de faire avec Hibernate est de modéliser une relation père/fils. Il y a deux approches différentes pour cela. Pour un certain nombre de raisons, la méthode la plus courante, en particulier pour les nouveaux utilisateurs, est de modéliser les deux relations Père et Fils comme des classes entités liées par une association <one-to-many> du Père vers le Fils (l'autre approche est de déclarer le Fils comme un <composite-element>). Il est évident que le sens de l'association un vers plusieurs (dans Hibernate) est bien moins proche du sens habituel d'une relation père/fils que ne l'est celui d'un élément cmposite. Nous allons vous expliquer comment utiliser une association un vers plusieurs bidirectionnelle avec cascade afin de modéliser efficacement et élégamment une relation père/fils, ce n'est vraiment pas difficile ! Les collections Hibernate sont considérées comme étant une partie logique de l'entité dans laquelle elles sont contenues ; jamais des entités qu'elle contient. C'est une distinction crutiale ! Les conséquences sont les suivantes : Quand nous ajoutons / retirons un objet d'une collection, le numéro de version du propriétaire de la collection est incrémenté. Si un objet qui a été enlevé d'une collection est une instance de type valeur (ex : élément composite), cet objet cessera d'être persistant et son état sera complètement effacé de la base de données. Par ailleurs, ajouter une instance de type valeur dans une collection aura pour conséquence que son état sera immédiatement persistant. Si une entité est enlevée d'une collection (association un-vers-plusieurs ou plusieurs-vers-plusieurs), par défaut, elle ne sera pas effacée. Ce comportement est complètement logique - une modification de l'un des états internes d'une entité ne doit pas causer la disparition de l'entité associée ! De même, l'ajout d'une entité dans une collection n'engendre pas, par défaut, la persistance de cette entité. Le comportement par défaut est donc que l'ajout d'une entité dans une collection créé simplement le lien entre les deux entités, et qu'effacer une entité supprime ce lien. C'est le comportement le plus approprié dans la plupart des cas. Ce comportement n'est cependant pas approprié lorsque la vie du fils est liée au cycle de vie du père. Supposons que nous ayons une simple association <one-to-many> de Parent vers Child. ]]> Si nous executions le code suivant Hibernate exécuterait deux ordres SQL: un INSERT pour créer l'enregistrement pour c un UPDATE pour créer le lien de p vers c Ceci est non seuleument inefficace, mais viole aussi toute contrainte NOT NULL sur la colonne parent_id. Nous pouvons réparer la contrainte de nullité en spécifiant not-null="true" dans le mapping de la collection : ]]> Cependant ce n'est pas la solution recommandée. La cause sous jacente à ce comportement est que le lien (la clé étrangère parent_id) de p vers c n'est pas considérée comme faisant partie de l'état de l'objet Child et n'est donc pas créé par l'INSERT. La solution est donc que ce lien fasse partie du mapping de Child. ]]> (Nous avons aussi besoin d'ajouter la propriété parent dans la classe Child). Maintenant que l'état du lien est géré par l'entité Child, nous spécifions à la collection de ne pas mettre à jour le lien. Nous utilisons l'attribut inverse. ]]> Le code suivant serait utilisé pour ajouter un nouveau Child Maintenant, seul un INSERT SQL est nécessaire ! Pour alléger encore un peu les choses, nous devrions créer une méthode addChild() dans Parent. Le code d'ajout d'un Child serait alors L'appel explicite de save() est un peu fastidieux. Nous pouvons simplifier cela en utilisant les cascades. ]]> Simplifie le code précédent en De la même manière, nous n'avons pas à itérer sur les fils lorsque nous sauvons ou effacons un Parent. Le code suivant efface p et tous ses fils de la base de données. Par contre, ce code n'effacera pas c de la base de données, il enlèvera seulement le lien vers p (et causera une violation de contrainte NOT NULL, dans ce cas). Vous devez explicitement utiliser delete() sur Child. Dans notre cas, un Child ne peut pas vraiment exister sans son père. Si nous effacons un Child de la collection, nous voulons vraiment qu'il soit effacé. Pour cela, nous devons utiliser cascade="all-delete-orphan". ]]> A noter : même si le mapping de la collection spécifie inverse="true", les cascades sont toujours assurées par l'itération sur les éléments de la collection. Donc, si vous avez besoin qu'un objet soit enregistré, effacé ou mis à jour par cascade, vous devez l'ajouter dans la colleciton. Il ne suffit pas d'appeler explicitement setParent(). Supposons que nous ayons chargé un Parent dans une Session, que nous l'ayons ensuite modifié et que voulions persiter ces modifications dans une nouvelle session en appelant update(). Le Parent contiendra une collection de fils et, puisque la cascade est activée, Hibernate a besoin de savoir quels fils viennent d'être instanciés et quels fils proviennent de la base de données. Supposons aussi que Parent et Child ont tous deux des identifiants du type Long. Hibernate utilisera la propriété de l'identifiant et la propriété de la version/horodatage pour déterminer quels fils sont nouveaux (vous pouvez aussi utiliser la propriété version ou timestamp, voir ). Dans Hibernate3, il n'est plus nécessaire de spécifier une unsaved-value explicitement. Le code suivant mettra à jour parent et child et insérera newChild. Ceci est très bien pour des identifiants générés, mais qu'en est-il des identifiants assignés et des identifiants composés ? C'est plus difficile, puisqu'Hibernate ne peut pas utiliser la propriété de l'identifiant pour distinguer un objet nouvellement instancié (avec un identifiant assigné par l'utilisateur) d'un objet chargé dans une session précédente. Dans ce cas, Hibernate utilisera soit la propriété de version ou d'horodatage, soit effectuera vraiment une requête au cache de second niveau, soit, dans le pire des cas, à la base de données, pour voir si la ligne existe. Il y a quelques principes à maîtriser dans ce chapitre et tout cela peut paraître déroutant la première fois. Cependant, dans la pratique, tout fonctionne parfaitement. La plupart des applications Hibernate utilisent le pattern père / fils. Nous avons évoqué une alternative dans le premier paragraphe. Aucun des points traités précédemment n'existe dans le cas d'un mapping <composite-element> qui possède exactement la sémantique d'une relation père / fils. Malheureusement, il y a deux grandes limitations pour les classes éléments composites : les éléments composites ne peuvent contenir de collections, et ils ne peuvent être les fils d'entités autres que l'unique parent.