Not directly related to the behaviour of the two variants, but there is also a difference for the optimizers. I've described it here: https://nhibernate.jira.com/browse/NH-3146
On Tuesday, August 7, 2012 8:22:37 AM UTC+2, Alexander I. Zaytsev wrote: > > The only difference I've found when a child entity is saving outside > of an association (has no magazine in your example) NH explicitly > inserts NULL to a FK (could be eliminated by > dynamic-update/dynamic-insert) > > INSERT > INTO > Child > (Name, ParentId, Id) > VALUES > (@p0, @p1, @p2); > @p0 = 'Bob's Child' [Type: String (4000)], @p1 = NULL [Type: Guid > (0)], @p2 = 3a55de1d-fa69-4014-9c22-a0a600c876e8 [Type: Guid (0)] > > All other things do work as before. > > > 2012/8/7 Fabio Maulo <[email protected]>: > > It may work but the concept is not the same. > > The not-nullable FK mean that NH have to track the unidirectional > > one-to-many (in the domain model) because it have to work as a > > mandatory bidirectional one-to-many<->many-to-one in the DB. > > With a nullable FK the relation is just an option and NH does not have > > to track the backref to the parent. > > a case: > > we have a video as standalone entity or a video associated to a > > magazine. in this case the magazine may have a video associted in a > > collection. the association de-association is performed with an UPDATE > > because you can INSERT the video before INSERT the magazine and then > > you can perform the association beteween the two entities. > > > > if we have a reletion as "the video can exists just when associated in > > a magazine" the unidirectional association represents a real > > parent-child (the child can't exists without the parent) and the > > association/de-association is performed via INSERT-REMOVE, as in a > > bidirectional relation, but with a unidirectional relation in the > > domain model. > > > > btw the matter is always the same: you can change the behavior passing > > all tests and then wait for bugs ;) > > just take care to do it inside an alpha release (in this case) > > -- > > Fabio Maulo > > > > > > El 06/08/2012, a las 18:00, "Alexander I. Zaytsev" > > <[email protected]> escribió: > > > >> Thanks, but I understand what this is and how it works. I do not > >> understand why this is applied only to not-null FK, as it works with > >> nullable FK too. > >> > >> If we will remove this check we will get consistent behavior for null > >> FK and for not-null FK > >> > >> 2012/8/7 Fabio Maulo <[email protected]>: > >>> The unidirectional one-to-many is a base feature of NH since 1.2 or > >>> before... > >>> > >>> What you are watching is a special case, exactly to manage and > optimize the > >>> case when the FK is not-nullable. > >>> Instead INSERT+UPDATE, as managed for no-mandatory unidirectional > >>> one-to-many (where the "item" side may have its own lifecycle), the > case for > >>> mandatory unidirectional one-to-many (FK not-nullable) works with > INSERT > >>> directly using a "fake" property for the backref to the parent. > >>> > >>> On Mon, Aug 6, 2012 at 11:10 AM, Alexander I. Zaytsev > >>> <[email protected]> wrote: > >>>> > >>>> Hi, all > >>>> > >>>> As you may know NH since 3.2 supports uni-directional one-to-many > >>>> associations. > >>>> > >>>> This was done by these commits > >>>> > >>>> > >>>> > https://github.com/nhibernate/nhibernate-core/commit/cb60f2169e7504ff83e601c555e42171f28ef9ff > > >>>> > >>>> > >>>> > https://github.com/nhibernate/nhibernate-core/commit/d6cc06bbfee56fc3ae224fdfdc862df4fdff0442 > > >>>> > >>>> I wonder why this fix is applied only to keys with not-null="true" > >>>> attribute? I've checked and it seems that all works perfectly without > >>>> checking that key is not nullable. > >>>> > >>>> As I understand the fix was ported from Hibernate, because there I've > >>>> found exactly the same code. > >>> > >>> > >>> > >>> > >>> -- > >>> Fabio Maulo > >>> >
