Thanks, Fabio. I never heard of the ghostbuster before, so I'll give that one a try.
Best regards, Eduardo On Tue, Nov 17, 2009 at 12:46 PM, Fabio Maulo <[email protected]> wrote: > mmmm.... you have a Ghost; > NH have detected a change in C. > Try to recreate the issue in a test but after run the Ghost-Buster. > > > 2009/11/17 Eduardo Scoz <[email protected]> > >> I'm not trying to blame NH, just trying to understand whats going on. It >> may very likely be my code, I understand that. Sorry if I passed the wrong >> impression. >> >> Here's what I have: >> >> A - mutable has one-to-many with B >> B - immutable, has one-to-one with C and one-to-many with D >> C and D - mutable >> >> >> I'm changing the state of A and doing a SaveOrUpdate(A), and that is >> causing SQL like: >> >> UPDATE A >> UPDATE C >> >> B is not getting saved, and neither is D. >> >> All I'm asking is: is this the expected behavior? If it is, great, I can >> deal with it. If its not, I can create a test case to help find the issue. >> >> Thanks Fabio. >> >> >> >> On Tue, Nov 17, 2009 at 12:26 PM, Fabio Maulo <[email protected]>wrote: >> >>> btw Eduardo, >>> don't try to find the solution inside NH, your problem is in your code... >>> you are changing something that shouldn't change. >>> >>> 2009/11/17 Fabio Maulo <[email protected]> >>> >>> no it shouldn't. >>>> What you are changing is not some value of the "middle" object but the >>>> state of a mutable object (the "right" side). >>>> example: >>>> - A has a one-to-one with B >>>> - A is NOT mutable >>>> - B is mutable >>>> >>>> When you change a property value in B what is changed ? only B and NH >>>> must track it. >>>> >>>> >>>> 2009/11/17 Eduardo Scoz <[email protected]> >>>> >>>>> Yeah, I can see that's the reason for the object to be saved. >>>>> >>>>> My point, though is: shouldn't the fact that the middle object is >>>>> immutable prevent the last object from getting saved when using a >>>>> one-to-one? This seems to be the behavior with sets that belong to the >>>>> middle object. >>>>> >>>>> >>>>> >>>>> On Tue, Nov 17, 2009 at 11:54 AM, Fabio Maulo <[email protected]>wrote: >>>>> >>>>>> You have answered your question by yourself. >>>>>> >>>>>> >>>>>> 2009/11/17 Eduardo Scoz <[email protected]> >>>>>> >>>>>>> Sorry, the only mutable object in my example is the "middle" one, >>>>>>> User. The right-side one (UserPreferences) is mutable as it needs to be >>>>>>> updated from a different part of the system. >>>>>>> >>>>>>> Thanks Fabio. >>>>>>> >>>>>>> >>>>>>> On Tue, Nov 17, 2009 at 11:33 AM, Fabio Maulo >>>>>>> <[email protected]>wrote: >>>>>>> >>>>>>>> and those object are mutable or not ? (I mean the "right" side of >>>>>>>> the one-to-one) >>>>>>>> >>>>>>>> 2009/11/17 Eduardo Scoz <[email protected]> >>>>>>>> >>>>>>>> Hi, >>>>>>>>> >>>>>>>>> I'm not sure if this is a bug or a feature, so I thought it would >>>>>>>>> be worthy to post here. >>>>>>>>> >>>>>>>>> It seems that during a save operation on a tree that contains >>>>>>>>> immutable objects, even though those objects are not updated (correct >>>>>>>>> behavior), objects that have a one-to-one relationship to those ones >>>>>>>>> get >>>>>>>>> updated. >>>>>>>>> >>>>>>>>> For example: >>>>>>>>> >>>>>>>>> I have a object UserData, with a many-to-one to User with a >>>>>>>>> one-to-one UserPreferences. >>>>>>>>> User in this case is immutable and kept in read-only cache. >>>>>>>>> When I do a save on the UserData object, that object gets saved, >>>>>>>>> and so does UserPreferences. >>>>>>>>> >>>>>>>>> Is that the correct behavior? I would expect only UserData to be >>>>>>>>> saved. Sets that are part of User are not updated. >>>>>>>>> >>>>>>>>> Thanks guys, >>>>>>>>> >>>>>>>>> Eduardo Scoz >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Fabio Maulo >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Fabio Maulo >>>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> Fabio Maulo >>>> >>> >>> >>> >>> -- >>> Fabio Maulo >>> >> >> > > > -- > Fabio Maulo >
