I have a very simple unidirectional mappings. see below:
public ContactMap()
{
Id(x => x.Id).GeneratedBy.Assigned();
Map(x => x
You have to set "updatable"=false
to your key to prevent update.
public ContactMap()
{
Id(x => x.Id).GeneratedBy.Assigned();
Map(x => x.Name);
References(x => x.Device);
HasMany(x => x.Numbers)
.Not.Inverse()
.Not.KeyNullable()
.Not.KeyUpdate() // HERE IT IS
.Cascade.AllDeleteOrphan()
.Not.LazyLoad()
.Fetch.Subselect();
Table("Contacts");
}
Try setting inverse
to true
on the mapping and assigning the relationship in code.
Inverse
means that the child is responsible for holding the ID of the parent.
e.g.
var contact = new Contact();
var phoneNumber = new PhoneNumber();
phoneNumber.Contact = contact;
That way, when you do the insert for the PhoneNumber record, NH can insert the ContactId without having to do a separate update.
That's what I used to do in NH 2, I would assume the behaviour still works the same in 3.
I don't know if you really can get rid of it.
Try using another id generator as native. It forces NH to insert the record only to get the id. The id is used for every entity in the session, so it can't do the insert later. It may case subsequent updates. Use hi-lo or something similar.
Edit
Why aren't you using a component in this case? You don't need to map the phone number separately, if they consist only of a number. Something like this (I'm not a FNH user, so it may be wrong):
public ContactMap()
{
Id(x => x.Id).GeneratedBy.Assigned();
Map(x => x.Name);
References(x => x.Device);
HasMany(x => x.Numbers)
.Not.Inverse()
.Not.KeyNullable()
.Cascade.AllDeleteOrphan()
.Not.LazyLoad()
.Fetch.Subselect()
.Component(c =>
{
Map(x => x.Number);
})
.Table("ContactNumbers");
Table("Contacts");
}
It is what Trevor Pilley said. Use inverse="true"
. If you choose not to have inverse="true"
, this is the consequence of that choice. You can't have it both ways.
You can't as of 3.2.0 BETA.
In v3.2.0 BETA an improvment to one-to-many introduced this anomaly to uni-directional one-to-many relationships (actually I am not sure if anormaly is what you would call this).
Before 3.2 you would need to set the foreign key to allow nulls for this type of relationship to work. So I would ignore the fact that this happens and just go with it. Otherwise you will need to change it to a fully bi-directional relationship.
- [NH-941] - One-Many Requiring Nullable Foreign Keys
Release notes or JIRA issue
edit Also the answer to the post you point to is to fix save null-save-update
rather than fixing the addtional update