Discussion :

[naf87]

Bonjour à tous,
Après avoir brièvement lu sur les Callbacks et les Entity Listeners, je pensais pouvoir auditer les opérations de manipulation de données (CRUD) de mon système. Mais au moment de me jeter à l’eau, je me rends compte qu’il n’est pas conseillé d’exécuter les méthodes du gestionnaire d’entité ou de l’objet Query dans ces méthodes (Bref, la spécification ne supporte pas cela) . Fort de ce constat, je me demande à quoi servent vraiment les callback et les entity listener ? Y-a-t ’il quelqu’un pour m’aider à voir clair ? Merci et bonne continuation à tous.

[Philippe Bastiani]

Effectivement... l'utilisation (et, l'utilité) des listeners dans JPA est assez limité puisque tu ne peux pas travailler avec l'entity manager

En se creusant la tête:
- auditing de tes entités
ou encore, le déclenchement d'évènements
- gestion des évènements CDI (mais, avec l'impossibilité d'injecter directement un bean CDI),
- gestion des messages via JMS,
- ...

a+
Philippe

[ruscov]

Personnellement j'utilise les listeners pour mettre automatiquement à jour certains champs de mes entity (lastmodified par exemple). Tu peux voir ça comme un trigger.

[naf87]

Là encore il y a une limitation. Il n'est pas possible de modifier les attributs relationnels de l'entité.

[DevServlet]

Là encore il y a une limitation. Il n'est pas possible de modifier les attributs relationnels de l'entité.

Bonjour, peux tu développer ça? Les CallBack comme dit dans le précédent post doivent être considérés comme des triggers agissant sur tous les champs d'une entité (changement de valeur) avant sa persistence.Ils ont toute leur utilité pour garantir une certaine cohérence de la base de donnée avant toute transaction.Personnellement je n'ai pas encore eu besoin d'invoquer un em dans un Listener.Toutefois l'inconvenient que je peux trouver à ce mécanisme c'est un risque d'oubli lors d'une maintenance applicative (évolution, non report de correction de bug), le même inconvenient que je trouve aux mécanismes trigger.

[naf87]

Là encore il y a une limitation. Il n'est pas possible de modifier les attributs relationnels de l'entité.

les attributs relationnels sont les attributs qui représente un ou plusieurs objet(s) d'une autre entité. Bref, le type de l'attribut est une Collection d'entité ou une entité. Et d'après la spécification (Si mon anglais est encore bon ), ce type d'attribut ne devrait pas être modifié dans les callbacks.

Et comme je l'ai dit dans mon tout premier post, je m'imaginais pouvoir renseigner ma table d'audit grâce aux callbacks. Étant donné qu'il y a des méthodes qui peuvent être exécutées avant et après la mise à jour, l'enregistrement et la suppression des données.

Ils ont toute leur utilité pour garantir une certaine cohérence de la base de donnée avant toute transaction

Si le mot cohérence ici fait uniquement allusion à la validation des données, je dirais qu'il y a un mécanisme de validation définit par la jsr 303, que je trouve assez intéressant.