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

Question

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

Forcing NHibernate to cascade delete before inserts

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

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

Answer 1

EDIT: После того, как вы сказали, что нет причин, вот причина. Допустим, у вас есть следующий сценарий:

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

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

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

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

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

• Support one-to-many list associations with constraints on both (owner_id, position) and (child_id)
• Non lazy loaded List updates done in wrong order, cause exception
• wrong insert/delete order when updating record-set
• Why does Hibernate perform Inserts before Deletes?
• Unidirection OneToMany causes duplicate key entry violation when removing from list

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

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