NHibernate ReferencesAny拉回错误的类型

时间:2011-07-21 23:38:10

标签: nhibernate fluent

我有一个名为AdministratorPrivilages的表,其中包含以下字段:

  • ID
  • 列表项
  • 成员Id
  • MemberType

现在,成员可以是两种类型(Enterprise和Express)。企业成员居住在企业表中。快递会员住在快递会员表中。我试着像我这样进行流畅的映射。

public class AdministratorPrivilegesMapping : ClassMap<AdministratorPrivileges>
    {
        public AdministratorPrivilegesMapping()
        {
            Id(x=>x.Id);
            Map(x => x.Value).Column("Value");
            ReferencesAny(x => x.Member)
                .EntityTypeColumn("MemberType")
                .EntityIdentifierColumn("MemberId")
                .IdentityType<Int32>()
                .AddMetaValue<ExpressMember>("Express")
                .AddMetaValue<Member>("Enterprise");

        }
    }

两个成员表都具有带有升序值的整数ID。当我尝试撤回与企业成员10关联的特权时,我获得了与Express Member 10关联的权限集。其他表都映射了旧的hbm映射文件。

我错过了一些明显的东西吗?我正在使用NHibernate 2.1和FluentNhibernate 1.1

2 个答案:

答案 0 :(得分:2)

我实际上是使用.Where()找到了解决方案。 我的情况有点不同,我有objectA和objectB。 objectA包含objectB,但objectB也包含objectBs的集合。

“对象A”:{   “someProp”:“(string)”,   “对象B”:{     “someProp”:“(string)”,     “comeCol”:[       “(对象B)”     ]   } }

因此objectB的“Parent”属性可以是objectB或objectA类型,这就是我需要在objectB的映射中使用ReferencesAny的原因。

映射看起来像

        ReferencesAny( x => x.Parent )
            .IdentityType< int >()
            .MetaType< string >()
            .EntityTypeColumn( "ParentType" )
            .EntityIdentifierColumn( "ParentId" )
            .AddMetaValue< objectA >( "E" )
            .AddMetaValue< objectB >( "S" )
            .Access.Property()
            .LazyLoad()
            .Cascade.All();

保存时所有这些都很有效,但是,检索时出现了问题,因为没有告诉框架检索什么,只是检索了所有内容。

所以现在这里是修复问题的集合的映射:

        HasMany( x => x.objectBs )
            .KeyColumn( "ParentId" )
            .Where( "ParentType = 'S'" )
            .Cascade.All()
            .LazyLoad();

希望它能帮助处于相同情况的任何人:)

答案 1 :(得分:1)

当我在Stackoverflow上发帖时似乎总是这样,我是一个完整的goober,并且错过了一些明显的东西,它通过一个良好的夜晚休息和一些咖啡因来清理自己。我需要查看ExpressMember和Member类的映射。原来没有根据对象类型适当过滤的包声明。最初,我认为我做了一个突破性的改变,实际上它实际上是一个非常古老的问题。两个不同类型的成员之间的id号冲突在很长一段时间内都不是问题,因为快递成员通常具有所有权限或者没有,大多数旧成员(首先在admin /下创建)特权被打破的plebe计划。)