Уникальное ограничение Nhibernate

Question

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

Есть ли способ указать Nhibernate сделать выбор перед вставкой в ​​естественные идентификаторы / уникальные ограничения?

Answer 1

Я закончил тем, что создал слушатель SaveOrUpdate для Nhibernate, так что объекты должны быть сохранены в базе данных, и я могу определить, нужно ли проверять их уникальность. Вместо того, чтобы просто выбрать, чтобы увидеть, существуют ли уникальные свойства объекта в базе данных, я делаю выбор для обновления (пессимистическая блокировка), чтобы строка была заблокирована, чтобы я мог безопасно объединить и обновить объект. Он создает O (2N) запросов, но если это станет проблемой, я мог бы упростить его до одного оператора слияния.

http://en.wikipedia.org/wiki/Merge_(SQL)

Answer 2

Так или иначе, вам придется идти в БД.

Однако вы можете сделать это более прозрачным способом с помощью NH Validator.

Прочитайте следующий пост от Фабио Мауло: http://fabiomaulo.blogspot.com/2009/10/validation-through-persistence-not.html

Answer 3

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

Answer 4

Обычно я решаю такой сценарий, просто пытаясь вставить (отправить изменения) и перехватить полученное исключение.

Вам все равно придется попасть в БД, поэтому сбойная ВСТАВКА будет стоить столько же (если не дешевле), чем SELECT ... И это безопаснее.