сложному условию (для БД) уникальность значения.
В базе создать уникальный partial constraint невозможно (Postgres)
Реализовано это так, что валидация дергает JPA репозиторий, перед этим выставив
entityManager.setFlushMode(FlushModeType.COMMIT);
Понятно, что это достаточно наивный подход, учитывая кейсы, где может быть конкурентная запись с нескольких инстансов
Не смотря на это есть вопрос: может ли Hibernate, во время валидации, увидеть предыдущие entity, которое было передано в saveAll? Что-то типа Read Uncommitted, но на уровне EntityManager кеша
SimpleJpaRepository реализует saveAll через
while(var3.hasNext()) {
S entity = var3.next();
result.add(this.save(entity));
}
и мне казалось, что оно может работать. Может, кто-то сталкивался с подобным? Спасибо большое)
UPD: Валидация настроена на Hibernate хук (группа) javax.persistence.validation.group.pre-persist
Если проверяется сохраняемая пачка, то почему не осуществить валидацию напрямую руками? Какую валидацию производите, что её нельзя записать правилами в схеме бд? Если это возможно, то можно пример?
Есть желание инкапсулировать все валидации в схеме/сущности. Понимаю, что это от части Анти-паттерн, но в моем кейсе не применим, т.к. интерсует только CRUD
Есть хак ещё с отдельным ключём - стрингой, конкатенацией все филды загоняешь в строку, все. Главное следить чтобы стринг не был длинным.
Щас могу сказать чушь, но, я могу представить, что у меня где-то есть функция, которая мне аккуратно достанет максимальную версию для опр. названия и сложит все это в один ключик.
Обсуждают сегодня