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

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

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

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

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


java hibernate database-schema database-migration hibernate-envers
person Sakuraba    schedule 23.04.2011    source источник

Ответы (3)


arrow_upward
4
arrow_downward

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

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

person Ryan Stewart    schedule 04.06.2012

arrow_upward
2
arrow_downward

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

person Gonzalo Garcia Lasurtegui    schedule 30.07.2011
comment
Спасибо! Обновил вопрос в соответствии с вашим ответом. - person Sakuraba; 01.08.2011
comment
Я пока не понимаю, как это не проблема? Если, например, у меня есть один столбец, который будет удален и заменен двумя столбцами. Сущность обновлена, и я обновил таблицу истории, чтобы она содержала 2 новых столбца, но что должно произойти с удаленным столбцом в таблице истории? Следует ли его удалить, а историю манипулировать? Должен ли он остаться и позволить таблице истории бесконечно расти для каждой манипуляции? Дело не в ошибке компиляции, потому что, конечно, она скомпилируется и заработает. - person Thomas Stubbe; 06.10.2020

arrow_upward
1
arrow_downward

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

9.3. @OneToMany+@JoinColumn

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

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

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

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

person James Gan    schedule 04.06.2012