Java
Hibernate Envers, la librairie JAVA pour le suivi des actions en BDD
Léa Joret, Développeuse Fullstack @DeliaTechnologies
December 13, 2023
8 min
Est-ce qu’il vous est déjà arrivé, lors d’un projet personnel ou professionnel, de devoir suivre manuellement les actions de création/modification/suppression d’une entité de BDD ? Pour cela, il faut créer une nouvelle table, l’entité associée, gérer manuellement la sauvegarde des actions menées sur cette entité. Plus le nombre de tables et d’actions à superviser est élevé, plus le risque d’erreur ou d’oubli l’est également.
Heureusement, la librairie Java Hibernate Envers est là pour nous simplifier la vie !
Pour cela, il vous suffit d’importer la librairie java dans votre projet. Par exemple, si vous utilisez Maven, il faut ajouter dans le pom du projet :
Pour suivre les actions sur une entité de BDD, il suffit d’annoter l’entité Java avec @Audited
De cette manière, une nouvelle table hero_aud sera créée en BDD (en code first), avec uniquement les champs que l’on souhaite auditer. A l’exception du champ @Id, les champs annotés avec @NotAudited ne seront pas suivis.
Deux colonnes supplémentaires sont présentes dans les tables d’audit
- 0 : création
- 1 : modification
- 2 : suppression
Félicitations, le suivi des actions est désormais mis en place pour une entité !
Afin de suivre le lien 1-n entre deux tables, il faut absolument empêcher l’audit sur la relation @OneToMany. L’audit est porté par la relation @ManyToOne. Automatiquement, la relation sera suivie dans la table d’audit, colonne hero_id.
Suivre l’audit sur une table de mapping peut paraître compliqué, mais il faut d’abord déterminer le besoin attendu.
Premier cas
Suivre l’entité 1, l’entité 2 et la table de mapping.
Il suffit d’annoter les deux entités avec @Audited, et automatiquement la table de mapping sera auditée.
Deuxième cas
Suivre uniquement l’entité 1 et la table de mapping.
@Audited(targetAuditMode = RelationTargetAuditMode.*NOT_AUDITED*) permet de dire à Hibernate Envers de ne pas auditer la table PlayerEntity.
L’entité PlayerEntity ne comporte par l’annotation @Audited.
C’est possible de renommer les tables d’audition. Deux méthodes :
La table revinfo, basiquement, contient : l’identifiant de l’action et la date à laquelle cette action est effectuée.
Il est possible d’étendre ces informations en rajoutant des colonnes. Par exemple, en portant l’identifiant technique de la personne ayant fait cette action.
Il va falloir en premier lieu créer une entité qui étend DefaultRevisionEntity, soit la classe représentant la table revinfo.
Dans cette classe, on défini les colonnes que l’on souhaite rajouter à la table revinfo, utilisateurId dans l’exemple ci-dessus.
Il va ensuite falloir créer la classe HistorisationListener, utilisée dans l’annotation @RevisionEntity.
Cette classe nous permet de définir la manière dont les nouvelles colonnes seront alimentées. Elle sera appelée à chaque fois qu’une action doit être historisée.
La librairie Hibernate Envers est fortement couplée aux méthodes portées par la classe JpaRepository.
Par exemple, si une modification est faite directement en BDD, elle ne sera pas prise à compte par Hibernate Envers.
Dans le même cas, si une modification est apportée par une requête JPA annotée par @Modifying, elle ne sera pas auditée. Un exemple ci-dessous de requête qui vient modifier directement une entité en BDD et non prise en compte par Hibernate Envers :
Si, sur votre projet, il est nécessaire de mettre en place un suivi des actions sur plusieurs de vos tables de BDD et que toutes les méthodes d’ajout/modification/suppression passent par les méthodes fournies par JPA, pourquoi ne pas essayer Hibernate Envers ? Vous m’en direz des nouvelles !
Réservez un moment avec notre équipe RH en quelques clics, pour voir ensemble le meilleur moyen de nous rejoindre. Vous avez des questions sur Delia Technologies ? C'est le moment de les poser !
Rencontrer notre équipe