Shouldn't two-way mappings have one end set as Inverse() when automapping?

[stachenov]

Take Examples.FirstAutomappedProject from the solution. It has

    public virtual IList<Employee> Staff { get; set; }

in Store and

    public virtual Store Store { get; set; }

in Employee. Now, with default mappings it generates a lot of INSERTs for employees, followed by a lot of UPDATEs to set the store. Quoting NHibernate Reference, “This is not only inefficient, but also violates any NOT NULL constraint on the parent_id column”. In this case there is no NOT NULL constraint, but it is sure nice to have one when you need it! Doing .ExportTo on the generated mappings confirms the suspicion that Fluent NHibernate does not set any end of the relationship as Inverse().

Of course, adding

            .Override<Store>(store => store.HasMany(s => s.Staff).Inverse());

to the mapping helps, but why isn't it the default setting for such relations? Is it by design or is it a bug/limitation?

[hazzik]

It is up to user to decide which end should own the relationship. I usually set inverse with convention (not overrides).