NHibernate 一对一映射 - 奇怪的连接？
我在 NHibernate 一对一映射方面遇到一些问题。我正在使用 Fluent Nhibernate，并在这篇博客文章中建立了我的映射： http://brunoreis.com/tech/ Fluent-nhibernate-hasone-how-implement-one-to-one-relationship/
表格片段：
dbo.Store
---------
Id : int
dbo.CheckoutSettings
---------
StoreId :int (FK to dbo.Store.Id)
这是一些 HBM：
<class xmlns="urn:nhibernate-mapping-2.2" schema="Management" mutable="true" name="Store" table="Streo">
<id name="Id" type="System.Int32, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" unsaved-value="0">
<column name="Id" />
<generator class="native" />
</id>
<one-to-one cascade="all" class="CheckoutSettings" constrained="false" name="CheckoutSettings" />
</class>
<class xmlns="urn:nhibernate-mapping-2.2" schema="Management" mutable="true" name="CheckoutSettings" table="CheckoutSettings">
<id name="StoreId" type="System.Int32, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089">
<column name="StoreId" />
<generator class="foreign">
<param name="property">Store</param>
</generator>
</id>
<one-to-one class="Store" foreign-key="FK_CheckoutSettings_StoreId" name="Store" />
</class>
事情似乎在本地工作，但在我们的测试服务器上，我遇到保存错误，例如意外行数：0（预期：1）。另外，在加载过程中，我看到奇怪的 sql 连接：
select (columns)
from checkoutsettings c0
left outer join store s on keys
left outer join checkoutsettings c1 on keys
where c0.Storeid = id
并且这不会返回任何内容，因为结账设置可能没有商店的行。
有什么想法吗？
I'm having some problems with NHibernate one to one mapping. I'm using Fluent Nhibernate, and basd my mappings on this blog post: http://brunoreis.com/tech/fluent-nhibernate-hasone-how-implement-one-to-one-relationship/
A snippit of the tables:
dbo.Store
---------
Id : int
dbo.CheckoutSettings
---------
StoreId :int (FK to dbo.Store.Id)
Here's some HBMs:
<class xmlns="urn:nhibernate-mapping-2.2" schema="Management" mutable="true" name="Store" table="Streo">
<id name="Id" type="System.Int32, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" unsaved-value="0">
<column name="Id" />
<generator class="native" />
</id>
<one-to-one cascade="all" class="CheckoutSettings" constrained="false" name="CheckoutSettings" />
</class>
<class xmlns="urn:nhibernate-mapping-2.2" schema="Management" mutable="true" name="CheckoutSettings" table="CheckoutSettings">
<id name="StoreId" type="System.Int32, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089">
<column name="StoreId" />
<generator class="foreign">
<param name="property">Store</param>
</generator>
</id>
<one-to-one class="Store" foreign-key="FK_CheckoutSettings_StoreId" name="Store" />
</class>
Things seem to work locally, but on our test server I get errors saving, such as Unexpected row count: 0 (expected: 1). Also during loading I see odd sql joins:
select (columns)
from checkoutsettings c0
left outer join store s on keys
left outer join checkoutsettings c1 on keys
where c0.Storeid = id
And this doesn't return anything as checkout settings may not have a row for the store.
Any ideas?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您应该将 CheckoutSettings 到 Store 的关系映射为多对一，并将 unique 设置为 true：
从 Store 到 CheckoutSettings 使用带有 property-ref 的一对一：
您还应该注意，因为 Store 实体中的 CheckoutSettings-property可以为 null 当您获取商店时，NHibernate 会生成到 CheckoutSettings 表的联接。这是因为 NHibernate 必须知道数据库中是否存在用于获取的存储的 CheckoutSettings，以便在不存在时将 CheckoutSettings-property 设置为 null。
You should map the relation from CheckoutSettings to Store as many-to-one with unique set to true:
From Store to CheckoutSettings use one-to-one with property-ref:
You should also note that because the CheckoutSettings-property in the Store entity can be null NHibernate generates a join to CheckoutSettings table when you fetch a store. This is because NHibernate must know is there CheckoutSettings for the fetched store in the database so that it can set the CheckoutSettings-property null if there isn't one.
经过进一步调查，我们发现一些触发器在插入和更新时做了奇怪的事情。一旦我们弄清楚了这一点，我们就能够做出改变来解决问题。
After further investigation we discovered that we had some triggers doing odd things on insert and update. Once we figured this out, we were able to make changes that resolved the issue.