Как Envers справляется с изменениями схемы?

Question

Я думаю о переходе с самореализуемого решения для управления версиями на Hibernate Envers, но пока не совсем уверен. Я много об этом читал, но меня беспокоят изменения схемы и то, как Envers справляется с ними после историзации данных в соответствии со старой схемой.

Какой у вас опыт работы с Энверсом в этом отношении? Как вы справляетесь с изменениями схемы и существующими данными в Envers?

Обновление 1:

Это не просто удаление простых столбцов из таблицы, а, например, при изменении простого отношения Forein-Key в отдельную сущность с двумя отношениями 1: n (M2M с атрибутированными столбцами. Это «логическое» изменение в вашей модели данных. Как вы справляетесь с этим при использовании Envers, когда есть уже историзированы данные в соответствии со старой моделью? Есть ли альтернатива для ручного написания sql-скриптов и переноса их в новое представление?

Answer 1

По моему опыту, Энверс просто копирует каждое поле из вашей таблицы сущностей в свои таблицы аудита. Скопированные поля в таблицах аудита не имеют никаких ограничений, включая обнуляемость и ограничения внешнего ключа, поэтому нет проблем с добавлением или удалением таких ограничений в реальных таблицах. Любые виды отношений, которые вы добавляете к своим сущностям, будут просто новыми столбцами аудита и / или таблицами, добавленными в Envers, и вы должны правильно интерпретировать их в их историческом контексте.

Для вашего примера, если я правильно понимаю, при переключении с отношения на основе столбца соединения на соединение на основе таблицы соединения у вас просто будет старый столбец соединения, сосуществующий с таблицей соединения, и в этот момент Первого перестанут заселять в пользу второго. Ваша история будет полностью сохранена, включая тот факт, что вы сделали этот переход. Если вы хотите, чтобы все старые данные вписывались в новую модель в таблицах аудита, вы должны выполнить миграцию.

Answer 2

Не должно быть проблем с изменением существующей схемы, поскольку Envers использует ваши @Entities для создания таблиц аудита.Так что если вы добавляете или удаляете столбец из существующей таблицы, если это изменение отражено в вашем @Entity / @Audited JavaBean, все должно быть в порядке.

Answer 3

Рефакторинг внешнего ключа должен выполняться с Envers. Поскольку Envers создает таблицу соединения даже для отношения один-ко-многим, следует изменить его, чтобы он стал отношением многие-ко-многим. Я извлек один абзац из официального документа :

9,3. @ OneToMany + @ JoinColumn

Когда коллекция отображается с использованием этих двух аннотаций, Hibernate не генерирует таблицу соединений. Энверс, однако, должен сделать это, поэтому что когда вы читаете ревизии, в которых изменилось, вы не получите ложных результатов.

Чтобы можно было назвать дополнительную таблицу соединений, есть специальная аннотация: @AuditJoinTable, семантика которой похожа на JPA @ JoinTable.

Один особый случай - это отношения, отображаемые с помощью @ OneToMany + @ JoinColumn on одна сторона, и @ ManyToOne + @ JoinColumn (вставляемый = ложь, updatable = false) со многих сторон. Такие отношения на самом деле двунаправленная, но владельцем является коллекция (см. здесь).

Чтобы правильно проверить такие отношения с Envers, вы можете использовать @AuditMappedBy аннотация. Это позволяет вам указать обратное свойство (используя элемент mappedBy). В случае индексированных коллекций, столбец индекса также должен быть отображен в ссылочной сущности (используя @Column (inserttable = false, updatable = false) и указывается с использованием positionMappedBy. Эта аннотация повлияет только на то, как Энверс работает. Обратите внимание, что аннотация является экспериментальной и может измениться в будущем.