Unidirectional One To Many Without Nullable Foreign Key

Closed after final release of NH3.2.0GA

I was not thinking of adding a mapping in Foo. When I think a little deeper on it, I'm not sure mapping needs to change. Let's say Bar has this:

[HasMany(Access = PropertyAccess.FieldCamelcase, Lazy = true, Inverse = true,
Table = "Foo", ColumnKey = "BarId", Cascade = ManyRelationCascadeEnum.AllDeleteOrphan,
RelationType = RelationType.Set)]
public virtual ICollection<Foo> Foos

Assume Foo has no property Bar, and also that Foo.BarId is not nullable.

var bar = new Bar();
bar.AddFoo(new Foo());
barRepository.Save(bar);

Currently, in this scenario we get a SQL exception because NH will insert the new Foo without a BarId. But why? Before cascading, NH has inserted Bar and gotten the new Id. I have told NH that Foo is related to a Bar via Foo.BarId. It knows enough to insert any new foos with Foo.BarId populated, no?

This all seems pretty obvious to me, which means I'm probably missing something fundamental...

On the other hand, if I do this:

session.Save(new Foo())

...I will get SQL exception. This is the desired outcome. In my domain have expressed that Foo is strictly a member of the Bar aggregate. I have no business saving it but in the context of its aggregate.

The original idea of this post was to support making the FK not-nullable. There is another benefit. When NH inserts child entities for which it knows the identity of the parent already, why the two step process (INSERT without FK then UPDATE)? Seems needlessly inefficient.

Hm,
Just to be clear, I am asking to see the code that you writes in this scenario.

Let us say that we add this:

<many-to-one name="Bar" column="BarId" not-null="true" access="nhibernate-internal-storage"/>// implies no property

Now, show me the code that you think will make this happen.

Certainly we must tell NH that Foo is related to Bar in the database via Foo.BarId column. But is Foo.Bar property the only way to express this? Is it the best way to express it for a domain driven design? As Colin originally suggested, why not extend the mapping to handle it? Is there some insurmountable reason that Bar.Foos mapping cannot express this to NH?

Let's say we could. When a Bar is saved and cascades happen, NH knows what to put in Foo.BarId. But let's say I save Foo directly. There is no Foo.Bar so BarId will not be in the insert, hence null. Let's say that nullable=false on Foo.BarId. A SQL exception occurs. This is the correct result. It is what I want.