🌞 Hibernate выполняет SQL не в том порядке, в котором ты его написал
Код читается сверху вниз, а Hibernate так не работает. При flush'е Hibernate складывает все действия в ActionQueue и выполняет их в строго фиксированном порядке по типу операции, а не по порядку вызова в коде:
Классический пример с unique-ограничением:
repo.delete(oldRow); // (1) в коде сначала удаляем
repo.save
(newRow); // (2) потом вставляем с тем же unique-значением
// commit -> ConstraintViolationException
На flush Hibernate переставит это в INSERT → DELETE. Вставка отработает до удаления, ловит конфликт по уникальному ключу, и падает, хотя в твоём коде последовательность была валидной.
🟡 Варианты решения:
— явный flush() между операциями, чтобы зафиксировать порядок;
— deferred (отложенные) constraints на стороне БД;
— пересмотр модели, чтобы коллизии в принципе не возникало.
Главное не считать, что порядок методов = порядок SQL. Это не так (для Hibernate).
Java Библиотека | Мы в Телеграм
Код читается сверху вниз, а Hibernate так не работает. При flush'е Hibernate складывает все действия в ActionQueue и выполняет их в строго фиксированном порядке по типу операции, а не по порядку вызова в коде:
1. orphan removal
2. INSERT
3. UPDATE
4. удаление коллекций
5. обновление коллекций
6. вставка коллекций
7. DELETE
Классический пример с unique-ограничением:
repo.delete(oldRow); // (1) в коде сначала удаляем
repo.save
(newRow); // (2) потом вставляем с тем же unique-значением
// commit -> ConstraintViolationException
На flush Hibernate переставит это в INSERT → DELETE. Вставка отработает до удаления, ловит конфликт по уникальному ключу, и падает, хотя в твоём коде последовательность была валидной.
🟡 Варианты решения:
— явный flush() между операциями, чтобы зафиксировать порядок;
— deferred (отложенные) constraints на стороне БД;
— пересмотр модели, чтобы коллизии в принципе не возникало.
Главное не считать, что порядок методов = порядок SQL. Это не так (для Hibernate).
Java Библиотека | Мы в Телеграм