I agree with Fabio's suggestions. If your existing verification process didn't go anywhere near to the success of finding the root cause, you can try his. In my own words, his suggestions would be:
1. Use Ghostbusters test to find which property mapping causing the unexpected dirty property state. 2. If that (#1) didn't work either, recreate the circumstance in a simplified manner, still using parent-child like model, and then examine the result. If it would bring the expected result, then you can learn what went wrong in your case. If this didn't work, then you find a new bug in NH and you can report it in NH Jira by attaching your failing tests. -- Regards, Maximilian Haru Raditya On Wed, Apr 27, 2011 at 4:00 AM, Fabio Maulo <[email protected]> wrote: > Just an advise: > Instead spend time trying to explain what you are doing and which are the > results, I think that would be better a test with: > 1) the 2 domain-classes involved > 2) the mapping > 3) the test method showing the problem > > The whole "show" could be less than 100 lines (perhaps around 60). > > > On Tue, Apr 26, 2011 at 4:27 PM, PLen <[email protected]> wrote: > >> Yes, it looks like your three points are correct. I ran another test >> where I had 5 GROUPs, each containing 1 DOCUMENT. I did an NHibernate >> query that returned an ICollection with the 5 GROUP objects. I went >> through the in-memory DOCUMENT objects and changed a property value. >> I then did an NHibernate Update on just one of my GROUP objects. The >> result was that all 5 of my DOCUMENT objects were updated in the >> database. I was able to see in the output console that NHibernate did >> 5 updates: >> >> NHibernate: UPDATE RPT_DOCUMENT_BASE SET ........ >> >> I then went to add the "inverse=true" attribute to my <bag> as you >> suggested, but the results were the same: 5 updates. >> >> As for the session management, I do: >> >> 1) Open ISession for the search and keep it in memory. >> >> 2) Alter DOCUMENT properties to the in-memory objects. >> >> 3) Do an NHibernate Update on the GROUP (not the DOCUMENT, but the >> GROUP). When an update is being called, I get my session from #1 and >> do an Update using that session. As a note, I always update the GROUP >> rather than just the DOCUMENT because with any DOCUMENT change, I also >> make a "modified date" update change to the GROUP as well. >> >> If I do another search, I close/dispose the existing session and start >> over. Essentially, I keep my search session open in case I need to do >> an update or delete. If I do another search, then I know I can scrap >> the old search session and get a new one. This process does not >> impact the current scenario, however, as we are only dealing with the >> first session. >> >> Looking at Oskar's reply earlier, however, he is indicating that it is >> working as intended. Oskar, if you are reading this I am very >> confused by what you stated. Part of what you said was: >> >> ISession.Update() is used for making the session aware of an instance >> that was loaded from a _previous_ session - i.e. load in one session >> and perform changes in another. So if you load and perform changes on >> the object in the same session, you should not call Update() on it. >> >> What I found was that if I didn't use the SAME ISession (the same >> session that was used to retrieve the objects) when I went to do an >> Update call, I got an exception that the session had been closed and >> the update could not take place. I could only do a successful update >> on an object if I used the same session. Per your last sentence, how >> do you persist changes to the DB if you don't call Update() on the >> changed object? >> >> More confused - Peter >> >> -- >> You received this message because you are subscribed to the Google Groups >> "nhusers" group. >> To post to this group, send email to [email protected]. >> To unsubscribe from this group, send email to >> [email protected]. >> For more options, visit this group at >> http://groups.google.com/group/nhusers?hl=en. >> >> > > > -- > Fabio Maulo > > -- > You received this message because you are subscribed to the Google Groups > "nhusers" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/nhusers?hl=en. > -- You received this message because you are subscribed to the Google Groups "nhusers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/nhusers?hl=en.
