Alex, I can't remember the whole codebase. just take care, pass all tests and, please, change that behavior in a alpha because, in general, the real problem is visible in a complex scenario.
-- Fabio Maulo El 07/08/2012, a las 03:22, "Alexander I. Zaytsev" <[email protected]> escribió: > 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 >>>>
