Проверка уникальных ограничений не выполняется слишком поздно с помощью Spring Boot Starter Data JPA

Я очень удивлен уникальной функцией ограничения. Я разрабатываю приложение для весенней загрузки с базой данных H2 для модульного тестирования.

Одна из моих сущностей имеет уникальное ограничение. Под заголовками класса User.

@Entity
@Table(name = "user", uniqueConstraints = { @UniqueConstraint(columnNames = { "identifier" }) })
@SequenceGenerator(name = "user_pkey", sequenceName = "user_id_seq")

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

Перед тестовой функцией

@Before
public void before() {
        User user1 = new User();
        user1.setBlackListed(false);
        user1.setIdentifier("[email protected]");
        user1.setRefreshToken("azerty");          
        this.userDao.save(user1);
}

Мой тест

@Test(expected = DataIntegrityViolationException.class)
public void user_identifierUnicityTest() {
    User user4 = new User();
    user4.setBlackListed(false);
    user4.setIdentifier("[email protected]");
    user4.setRefreshToken("azerty4");
    User response = this.userDao.save(user4);
    this.userDao.findByIdentifier("[email protected]");
}

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

Целостность ограничения проверяется во время запроса выбора, а не вставки. Я не понимаю результата.

Это нормальное поведение ограничения уникальности?

Спасибо за ответы :)


spring-boot hibernate spring-data h2 unique-constraint
person j1704    schedule 01.01.2018    source источник

Ответы (1)


arrow_upward
6
arrow_downward

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

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

person Per Huss    schedule 01.01.2018
comment
Пожалуйста! Удачного кодирования с гибернацией, это потрясающий фреймворк! - person Per Huss; 02.01.2018
comment
Soory, я знаю, что этот вопрос старый, но я сталкиваюсь с той же проблемой, и мне интересно, как можно предотвратить спящий режим для сохранения данных, если они уже существуют в базе данных. Зачем делать ручную проверку или, может быть, настраиваемый валидатор? - person Alain Duguine; 11.02.2020
comment
@AlainDuguine Это зависит от многих вещей ... Создайте новый вопрос с более подробной информацией о вашем варианте использования и вашем коде! - person Per Huss; 12.02.2020
comment
Спасибо ! Я нашел свой ответ, создав repository.flush () в моем слое обслуживания. - person Alain Duguine; 12.02.2020