Проблема NHibernate с сопоставлением подклассов с подклассами, разделяющими отношения - PullRequest
0 голосов
/ 01 марта 2011

Я столкнулся с проблемой при реализации следующего сценария с NHibernate:

Существует таблица Foo со столбцами Foo_Id, Foo_RefType, Foo_RefId.В зависимости от значения в Foo_RefType (наш столбец дискриминатора, 'BAR' или 'BAZZ') у нас есть отношение либо к таблице Bar (Bar_Id, ...), либо к Bazz (Bazz_Id, ...).

Эта реляционная модель должна быть сопоставлена ​​с этими классами:

public abstract class Foo : BaseEntity
{
    public virtual long Id { get; set; }
}

public class FooBar : Foo
{
    public Bar Bar { get; set; }
}

public class FooBazz : Foo
{
    public Bazz Bazz { get; set; }
}

public class Bar : BaseEntity { ... }

public class Bazz : BaseEntity { ... }

Для этого свободно определялось следующее отображение (одна таблица на иерархию):

public class FooMap : ClassMap<Foo>
{
    public FooMap()
    {
        Table("Foo");
        Id(f => f.Id, "Foo_Id");
        DiscriminateSubclassesOnColumn<string>("Foo_RefType");
    }
}

public class FooBarMap : SubclassMap<FooBar>
{
    public FooBarMap()
    {
        DiscriminatorValue("BAR");
        References(f => f.Bar).ForeignKey("Foo_RefId");
    }
}

public class FooBazzMap : SubclassMap<FooBazz>
{
    public FooBazzMap()
    {
        DiscriminatorValue("BAZZ");
        References(f => f.Bazz).ForeignKey("Foo_RefId");
    }
}

Фу.Это отображение компилируется.Но давайте попробуем следующий фрагмент:

// ...
session.SaveOrUpdate(new FooBar{Bar = _someBar});
session.SaveOrUpdate(new FooBazz{Bazz = _someBazz});
session.Flush();
// ...

NHibernate правильно создает первую вставку.Но для второго утверждения NHibernate REUSES использует идентификатор BAR_ID вместо BAZZ_ID!То же самое верно, если оба оператора переключены, тогда NHibernate REUSES BAZZ_ID вместо BAR_ID в сгенерированном втором операторе вставки.

Я надеюсь, что смогу прояснить проблему.

Есть ли у васесть идеи как с этим справиться?Это ошибка в отображении?Это ошибка?Заранее спасибо!

...