Нарушение целостности нарушается при создании настраиваемой сущности ревизии с использованием спящего режима - PullRequest
0 голосов
/ 12 декабря 2018

У меня есть приложение, которое использует hibernate envers и имеет аудит для некоторых объектов.

Я хочу добавить несколько дополнительных столбцов в таблицы аудита и следовал стандартным инструкциям, которые я нашел в нескольких блогах.

Сначала я создал настраиваемую сущность ревизии:

@Entity
@RevisionEntity(UserRevisionListener.class)
public class UserRevEntity extends DefaultRevisionEntity {
    private String username;

    public String getUsername() { return username; }

    public void setUsername(String username) { this.username = username; }
}

, затем прослушиватель редакции:

public class UserRevisionListener implements RevisionListener {
    @Override
    public void newRevision(Object revisionEntity) {
        UserRevEntity exampleRevEntity = (UserRevEntity) revisionEntity;
        exampleRevEntity.setUsername("TEST");
    }
}

Проблема заключается в том, что когда приложение сохраняет сущность (давайтеназовите его MyEntity) он нарушает ограничение внешнего ключа для базы данных.

Я пришел к выводу, что до сих пор записывал envers в таблицу REVINFO, но теперь, посмотрев на запрос, который JPA отправляет в базу данных, я вижу, чтоон пишет в USERREVTABLE.Поскольку таблица, в которой сохраняется MyEntity, имеет ограничение внешнего ключа, ссылающееся на REVINFO, это вызывает нарушение ограничения.

Как я могу преодолеть эту проблему?Есть ли аннотации envers, чтобы исправить этот сценарий?

Пожалуйста, помогите, заранее спасибо.

1 Ответ

0 голосов
/ 12 декабря 2018

Самое простое решение - это сделать

@Entity
@Table(name = "REVINFO")
@RevisionEntity(UserRevisionListener.class) 
public class UserRevEntity extends DefaultRevisionEntity {
  ...
}

Если вы заметили, я явно добавил аннотацию @Table для решения проблемы.

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

В сценарии по умолчанию, где вы не предоставляете настраиваемую сущность ревизии, Энверс фактически использует класс и вручную отображает этот класс как сущность в конфигурации сопоставления Hibernate XML.В этом сценарии по умолчанию мы явно сообщаем ORM, что для этого класса используется вспомогательная таблица REVINFO.

Когда вы предоставляете свой собственный пользовательский объект редакции, это сопоставление сущностей фактически сначала обнаруживается ORM, поскольку оно являетсяреальная сущность в вашей доменной модели.Это означает, что Envers должен проверять сопоставления сущностей, которые ORM имеет во время начальной загрузки, и если он обнаружен с помощью @RevisionEntity, мы не отправляем сопоставление Hibernate XML с конфигурацией по умолчанию.

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

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

Добавьте @Table(name = "REVINFO"), и он будет вставлен в REVINFO, как всегда.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...