Я боролся с тем же самым.Реакция немного запоздала, но, возможно, будущие читатели выиграют.
Решение о разрешении использования нулевого ключа в качестве внешнего ключа для дочерней таблицы работает, но это может быть нежелательно с точки зрения проектирования базы данных, если ваш ребенок не можетв любом случае существует без родителя.Изменение структуры базы данных исключительно потому, что этого требует NHibernate, мне не нравится.Также было нежелательно переходить с двунаправленного на однонаправленный.Поэтому я попробовал всевозможные комбинации отображений.
Я обнаружил, что использование inverse = true решило проблему.Сначала я подумал, что это плохое поведение в NHibernate, поскольку inverse = true в основном объясняется тем, что ответственность за отношение лежит на дочерней коллекции, которую, как я думал, я уже рассмотрел, вручную обновляя дочерний и родительский элементы.Но эта ответственность больше относится к базе данных, чем к чему-либо еще.
Используя inverse = true, все еще можно удалить дочерний элемент, удалив его из родительского элемента, если у вас есть Cascade.AllDeleteOrphan в родительском элементе.На стороне карты все будет корректно обновлено.Если вы решите использовать Cascade.All, вы также должны явно удалить дочерний элемент.
Если родительский элемент не загружен, вы также можете сразу же удалить дочерний элемент, просто удалив его в текущем сеансе.Но это не работает, если родительский файл загружен, и в этом случае это приведет к каскадным проблемам повторного сохранения.
Суть для меня в том, что обратное работает.И я не нашел сценария, в котором инверсия = ложь дает мне лучшие результаты, но я мог бы вернуться к этому мнению, углубившись в NHibernate.