Почему NHibernate не удаляет сирот сначала?

Я пытаюсь понять, почему NHibernate обрабатывает каскадирование один-ко-многим (используя cascade = all-delete-orphan), как он это делает. Я столкнулся с тем же вопросом, что и этот парень:

Насколько я могу судить, NHibernate всегда выполняет вставки сначала, а затем обновляет, а затем удаляет. Для этого может быть очень веская причина, но я не могу для жизни понять, что это за причина. Я надеюсь, что лучшее понимание этого поможет мне придумать решение, которое я не ненавижу:)

Есть ли хорошие теории в этом поведении? В каком сценарии лишение сирот сначала не будет работать? Все ОРМ работают таким образом?

Ответы

Ответ 1

РЕДАКТИРОВАТЬ: после того, как вы сказали, что нет причин, вот причина. Допустим, у вас есть следующий сценарий:

public class Dog {
  public DogLeg StrongestLeg {get;set;}
  public IList<DogLeg> Legs {get;set;
}

Если вы сначала хотите удалить, и разрешите удалить все Dog.Legs, вы можете удалить StrongestLeg, что приведет к нарушению ссылки. Следовательно, вы не можете УДАЛИТЬ, прежде чем вы ОБНОВЛЯЕТЕ.

Предположим, вы добавили новую ногу, и что новая нога также является StrongestLeg. Затем вы должны ВСТАВИТЬ перед обновлением, чтобы нога имела идентификатор, который можно вставить в Dog.StrongestLegId.

Итак, вы должны ВСТАВИТЬ, ОБНОВИТЬ, а затем УДАЛИТЬ.

Также как nHibernate основан на Hibernate, я просмотрел Hibernate и обнаружил, что несколько человек говорили о той же проблеме.

И вот лучший ответ от них:

Gail Badner добавил комментарий - 21/Feb/08 2:30 PM: Проблема возникает, когда новый объект объединения с генерируемым идентификатором добавляется в коллекцию. Первый шаг при объединении объекта содержащий эту коллекцию, каскад сохранить новую ассоциацию организация. Каскад должен произойти до другие изменения в коллекции. Потому что уникальный ключ для этого нового объект объединения такой же, как сущность, которая уже сохраняется, ConstraintViolationException - это выброшены. Это ожидаемое поведение.