When I get back to home in about 2 weeks I plan to resume work on Net4/ISet support and merge this within a week or two. After that might be a good point to release an alpha?
/Oskar 2012/8/7 Fabio Maulo <[email protected]> > 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 > >>>> >
