Fluent NHibernate 错位重复字段
我想我误解了它的工作原理。这是我的流畅映射:
public class FunctionInfoMap : ClassMap<FunctionInfo>
{
public FunctionInfoMap()
{
Id(x => x.Id);
Map(x => x.Name);
Map(x => x.Signature);
Map(x => x.IsNative);
Map(x => x.ClassId);
References(x => x.Class, "ClassId");
HasMany(x => x.CallsAsParent).Inverse();
HasMany(x => x.CallsAsChild).Inverse();
Table("Functions");
}
}
public class CallMap : ClassMap<Call>
{
public CallMap()
{
CompositeId()
.KeyProperty(x => x.ThreadId)
.KeyProperty(x => x.ParentId)
.KeyProperty(x => x.ChildId)
.Mapped();
Map(x => x.ThreadId).Index("Calls_ThreadIndex");
Map(x => x.ParentId).Index("Calls_ParentIndex");
Map(x => x.ChildId).Index("Calls_ChildIndex");
Map(x => x.HitCount);
References(x => x.Thread, "ThreadId");
References(x => x.Parent, "ParentId");
References(x => x.Child, "ChildId");
Table("Calls");
}
}
public class SampleMap : ClassMap<Sample>
{
public SampleMap()
{
CompositeId()
.KeyProperty(x => x.ThreadId)
.KeyProperty(x => x.FunctionId)
.Mapped();
Map(x => x.ThreadId);
Map(x => x.FunctionId);
Map(x => x.HitCount);
References(x => x.Thread, "ThreadId");
References(x => x.Function, "FunctionId");
Table("Samples");
}
}
现在,当我将此架构创建到新数据库中时,SampleMap 中的 FunctionId 字段将出现在 Calls 表中。
create table Calls (
ThreadId INTEGER not null,
ParentId INTEGER not null,
ChildId INTEGER not null,
HitCount INTEGER,
FunctionId INTEGER,
primary key (ThreadId, ParentId, ChildId)
)
create table Samples (
ThreadId INTEGER not null,
FunctionId INTEGER not null,
HitCount INTEGER,
FunctionId INTEGER,
primary key (ThreadId, FunctionId)
)
我不明白为什么它在那里,因为它应该只存在于示例表中。
I think I'm misunderstanding something about how this works. This is my fluent mapping:
public class FunctionInfoMap : ClassMap<FunctionInfo>
{
public FunctionInfoMap()
{
Id(x => x.Id);
Map(x => x.Name);
Map(x => x.Signature);
Map(x => x.IsNative);
Map(x => x.ClassId);
References(x => x.Class, "ClassId");
HasMany(x => x.CallsAsParent).Inverse();
HasMany(x => x.CallsAsChild).Inverse();
Table("Functions");
}
}
public class CallMap : ClassMap<Call>
{
public CallMap()
{
CompositeId()
.KeyProperty(x => x.ThreadId)
.KeyProperty(x => x.ParentId)
.KeyProperty(x => x.ChildId)
.Mapped();
Map(x => x.ThreadId).Index("Calls_ThreadIndex");
Map(x => x.ParentId).Index("Calls_ParentIndex");
Map(x => x.ChildId).Index("Calls_ChildIndex");
Map(x => x.HitCount);
References(x => x.Thread, "ThreadId");
References(x => x.Parent, "ParentId");
References(x => x.Child, "ChildId");
Table("Calls");
}
}
public class SampleMap : ClassMap<Sample>
{
public SampleMap()
{
CompositeId()
.KeyProperty(x => x.ThreadId)
.KeyProperty(x => x.FunctionId)
.Mapped();
Map(x => x.ThreadId);
Map(x => x.FunctionId);
Map(x => x.HitCount);
References(x => x.Thread, "ThreadId");
References(x => x.Function, "FunctionId");
Table("Samples");
}
}
Now when I create this schema into a fresh database, that FunctionId field from SampleMap winds up in the Calls table.
create table Calls (
ThreadId INTEGER not null,
ParentId INTEGER not null,
ChildId INTEGER not null,
HitCount INTEGER,
FunctionId INTEGER,
primary key (ThreadId, ParentId, ChildId)
)
create table Samples (
ThreadId INTEGER not null,
FunctionId INTEGER not null,
HitCount INTEGER,
FunctionId INTEGER,
primary key (ThreadId, FunctionId)
)
I don't understand why it's there, since it should only exist in the Samples table.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
您不应同时映射外键和多吨一关系。 而不是
映射使用外键的多对一
我不知道这是否能解决您的问题, 。另外,我强烈建议不要使用复合键。将它们替换为代理键(身份)和唯一索引。
You should not map both the foreign key and the many-ton-one relationship. Instead of
map the many-to-ones which use the foreign keys
I don't know if this will solve your problem. Also, I strongly advise against using composite keys. Replace them with surrogate key (identity) and unique indexes.
我终于或多或少地弄清楚了问题所在。 FunctionInfoMap 上的这对集合让 NHibernate 感到困惑,因为它们实际上并不指向任何地方。添加 KeyColumn 条目将它们链接到父级和子级关联更正了杂散字段。
I finally figured out the problem, more or less. The pair of collections on FunctionInfoMap were confusing NHibernate, since they don't actually lead anywhere. Adding KeyColumn entries to link them up to the Parent and Child associations corrected the stray field.