Я получил полиморфное отношение, как в следующем примере:
public class A
{
public virtual Guid Id { get; set; }
public virtual string Name { get; set; }
}
Класс B и C, включающий в себя список A:
public class B/C
{
public virtual Guid Id { get; set; }
public virtual string Name { get; set; }
public virtual IList<A> As { get; set; }
public virtual SomeParent Parent { get; set; }
}
Моя цель - запросы типа
session.Linq<B>().Where(x => x.Parent == someParent && x.As.Contains(someA));
В настоящее время я настроил отношение «многие ко многим» между B => A и C => A, используя таблицу общих ссылок, потому что я хочу, чтобы все мои ссылки были в одной таблице.В этом примере экспорта NH Shema создает 4 таблицы, A, B, C и ChildToA.
HasManyToMany(x => x.As)
.AsBag()
.Table("XX_ChildToA")
.ParentKeyColumn("Child_ID")
.ChildKeyColumn("A_ID")
.Cascade.All()
Это работает нормально, если вы используете только один дочерний тип, потому что экспорт shema генерирует внешний ключ, ограничивая «Child_ID» идентификаторами любой таблицы, к которой он обращается первым при экспорте (B в данном случае).
var b = session.Get<B>(id);
b.As.Add(someA);
tx.Commit(); // works fine
var c = session.Get<C>(id);
c.As.Add(someA);
tx.Commit(); // crashes because of FK constraint
Могу ли я остановить FluentNHibernate от создания этого FK?Пока я искал в Google эту проблему, я заметил образцы HBM с атрибутами foreign-key = "no" в отношениях "многие к одному".Так что NHibernate должен быть в состоянии решить эту проблему, верно?Тем не менее, я хотел бы сохранить свои свободные отображения, потому что таким образом я могу создать общий базовый класс отображения для всех моих дочерних типов, и в настоящее время все наши отображения являются отображениями FNH.