Рассмотрим случай, когда необходимо отслеживать изменения, которые пользователь или какая-либо система вносит в данные в базе данных. Иногда должностные лица требуют иметь возможность получать историю этих изменений, иногда мы просто хотим получить представление о том, что произошло в системе, для целей обработки ошибок/отладки/мониторинга, или, возможно, мы просто хотим иметь исторические данные о том, как, например, изменился рост ребенка. Все эти случаи могут быть охвачены довольно простым решением – протоколированием последнего состояния данных на момент изменений. Это называется контрольным журналом.
- Изменения в таблицах отслеживаются автоматически всякий раз, когда мы вызываем операции сохранения, обновления или удаления на уровне нашего репозитория;
- Возможность легко запрашивать журнал аудита.
Мы собираемся работать с нашим проектом User service , который использовался для предыдущей статьи в серии. Наша цель – иметь контрольный журнал всех изменений пользовательских данных.
В Spring Data есть механизм, называемый Spring Data Envers, который позволяет получать доступ к ревизиям сущностей, управляемым Hibernate Envers. Он автоматически запишет моментальные снимки сущности пользователя при выполнении операции обновления, сохранения и удаления в отдельную таблицу (user_history в нашем случае). Давайте посмотрим, как это можно реализовать.
Уважительная зависимость должна быть добавлена, чтобы включить ее в нашем проекте: группа компиляции: 'org.springframework.data', имя: 'spring-data-envers'
Компонент Repository factory bean должен быть изменен. Это можно сделать, добавив Enablejparepositories(или изменив, если он у вас уже есть) в классе Application(класс, отмеченный @Configuration) с помощью EnversRevisionRepositoryFactoryBean в качестве класса factory bean: @enablejparepositories(repositoryFactoryBeanClass.class )
Проверенная аннотация должна быть добавлена, чтобы включить контрольный журнал конкретной сущности: @Entity @Data ) ) @Проверенный Пользователь открытого класса { ...
Репозиторий должен расширить еще один интерфейс – Репозиторий ревизий. Это позволяет репозиторию получать доступ к ревизиям объекта, когда вы захотите получить все ревизии данных или какую-то конкретную: общедоступный интерфейс UserRepository расширяет RevisionRepository Integer>, CrudRepository Long> { ... Integer>, CrudRepository Long> {
Нет необходимости определять сущность user_history. Вам следует просто указать суффикс, который Spring Data добавит автоматически к имени объекта и будет использовать в качестве имени таблицы, в которую будет записан контрольный журнал. Он настраивается в application.yaml: spring.jpa.properties.org.hibernate.envers.audit_table_suffix: _history
В нашем случае user_history – это таблица, которая будет использоваться для журнала аудита. Давайте настроим Spring JPA для создания таблиц при запуске приложения (установите spring.jpa.generate-ddl в значение true и spring.jpa.hibernate.ddl-auto для создания), запустите приложение и посмотрите на эту таблицу. Теперь у нас есть таблицы user и usera_history в базе данных. таблица user_history содержит два дополнительных столбца по сравнению с таблицей user – rev и rev type. Редакция сохраняется в столбце rev. тип rev определяет тип операции, которая была выполнена над объектом:
- 0 – ДОБАВИТЬ – Была вставлена строка таблицы базы данных;
- 1 – MOD – Обновлена строка таблицы базы данных;
- 2 – DEL – Строка таблицы базы данных была удалена.
Переходим к тесту. Необходимо создать первого пользователя. В этом случае в пользовательской базе данных будут созданы новые записи с типом rev 0 и первой ревизией. ревизия – одна для каждой таблицы, а не для каждой сущности, это важно. Итак, если я вставлю следующего пользователя, то будет взята последняя редакция (скажем, 2) и увеличена на 1 (3). Затем, если я вставлю следующего пользователя, его редакция будет равна 4. И так далее. Запись пользователя будет обновлена, но в таблице user_history появится новая запись со следующей редакцией в случае операции обновления для существующего пользователя.
Spring Data Envers – это очень удобный механизм для отслеживания аудита. Он также поддерживает более сложные сопоставления. Например, проверяемая аннотация может быть помещена не на уровне класса, а на какое-то конкретное поле, и только это поле будет проверяться. Я рекомендую вам проверить его Javadoc и проверить Hibernate doc , чтобы получить больше информации.
Оригинал: “https://dev.to/baseblocks/how-to-2-audit-trail-using-envers-jhi”