Обратите внимание, что необработанные исключения по-прежнему довольно смертельны; вы можете реально использовать это только для регистрации или, может быть, поспешного закрытия. Ни этот, ни Application.ThreadException
не могут использоваться как глобальный приемник для ошибок.
. Лучший подход - добавить правильную обработку - например, вокруг всей вашей Main()
логики. Обратите внимание, что даже этот не может поймать несколько исключений, таких как ошибки во время загрузки формы (которые становятся особенно неприятными - вы можете поймать их приложением отладчика, но не без него).
Я думаю, что проблема здесь в том, что соглашение «HasOne» означает, что вы указываете на другую вещь (стандартный реляционный способ сказать «многие к одному» / «один к одному»); Помещая Task_ID в документ, фактическая связь - это HasMany, но у вас есть какое-то неявное понимание того, что на одну задачу будет только один документ.
Извините - я не знаю, как это исправить, но мне будет интересно посмотреть, каково это решение (я не использую NHibernate или Fluent NHibernate, но я изучал его для использования в будущем). Решение (от кого-то с очень малой идеей) состояло бы в том, чтобы сделать Documents коллекцией в Task, а затем предоставить свойство Document, которое возвращает первое в коллекции (используя интерфейс, который скрывает свойство Documents, чтобы никто не думал, что они могут добавить новинки к нему).
Просматривая документацию и обдумывая ответ eulerfx, возможно, этот подход будет выглядеть примерно так:
References(x => x.Document)
.TheColumnNameIs("ID")
.PropertyRef(d => d.Task_ID);
РЕДАКТИРОВАТЬ: Просто этот ответ имеет соответствующее решение: правильный путь - обновить схему базы данных, чтобы она соответствовала цель кода. Это означает добавление DocumentID к таблице задач, поэтому существует связь «многие к одному» между задачей и документом. Если изменения схемы были невозможны, References () будет подходящим решением.
Вы должны использовать:
Ссылки (x => x.Document, "DocumentIdColumnOnTask")
Я пробовал это решение:
только в Документе:
mapping.HasOne(x => x.Task).ForeignKey("Task_ID").Constrained().Cascade.All();
Я боролся с той же проблемой «Имею один» и, наконец, обнаружил, что это сработало:
public class ParentMap : ClassMap<Parent>
{
public ParentMap()
{
Id(x => x.Id);
HasOne(s => s.Child).Cascade.All();
}
}
public class ChildMap : ClassMap<Model.Child>
{
public ChildMap()
{
Id(x => x.Id);
HasOne(s => s.Parent).Constrained().ForeignKey();
}
}
Я столкнулся с той же проблемой сегодня. Я считаю, что хитрость заключается не в том, чтобы использовать .ForeignKey (...) с отображением .HasOne, а вместо этого использовать .PropertyRef (...). Ниже описано, как я определяю отношение «один к одному» между Организацией (Родитель) и ее Администратором (Дочерний):
HasOne(x => x.Admin).PropertyRef(r => r.Organisation).Cascade.All();
Администратор имеет простую ссылку на Организацию, используя ее Внешний ключ:
References(x => x.Organisation, "ORAD_FK_ORGANISATION").Not.Nullable();
При извлечении Организации это приведет к загрузке правильной записи администратора и правильному каскадному обновлению и удалению.
Как указал eulerfx,
структура таблицы указывает, что может быть несколько документов для задачи
, и Крис заявил:
Помещая Task_ID в документ, фактическая связь - это HasMany, но у вас есть какое-то неявное понимание того, что на одну задачу будет только один документ.
Это, конечно, правильно, поэтому я перевернул его, чтобы у Task был обнуляемый Document_Id.
Спасибо вам обоим за вашу помощь!
Я подбросил монету за принятый ответ, если бы я мог поставить галочку и то, и другое!