Thanks, we do generally override GetHashCode and Equals -- but I'll take 
another look, in case we missed these somewhere.

Peter



On Saturday, April 5, 2014 9:15:19 AM UTC-4, Vinicius G. D. Menezes wrote:
>
> Hi Peter, 
>
> I've been working with different projects at the company I work for and I 
> could hint you that the updates also depend on the lifecycle of your 
> ISession. Since ISession can only work for one Thread, you might be in a 
> position of creating and destroying it too early, therefore making 
> nhibernate update your objects without necessity.
>  Have you tried implementing IComparable, overding .GetHashCode() and 
> .Equals() methods and interfaces for your objects? NHibernate compares the 
> objects to track it's differences, sometimes a reference difference can 
> change your object Hashcode making NHibernate "think" it's an update.
>
> Generally Value Objects will need that kind of implementation I suggested. 
> Would you be able to detail your problem a bit more?
>
> Vinicius Menezes
>
>
> On Mon, Mar 17, 2014 at 7:25 AM, Carel Blumenstock 
> <[email protected]<javascript:>
> > wrote:
>
>> We are using fluent mappings, in order to have changes to child lists not 
>> trigger a version update of the parent we had to state as such in mapping 
>> like Not.OptimisticLock(), hth
>>
>> Op maandag 10 maart 2014 20:12:27 UTC+1 schreef Peter V:
>>
>>> We're using NHibernate where the DB can be updated by either a user (via 
>>> GUI) or external systems (via background message handlers).  Our DB schema, 
>>> by the way, uses a lot of joins.  
>>>
>>> So what can happen is, we can get multiple background messages that 
>>> provide exactly the same information, and so trigger repeated writes to the 
>>> DB across all the joined tables that don't actually change anything (other 
>>> than the version).
>>>
>>> What I'm trying to figure out is, for performance reasons, is there a 
>>> way to prevent NH from updating the DB if a value hasn't changed?
>>>
>>> So when an object's setter is called, NH should first read the current 
>>> value from the DB, and if the new value is the same, do nothing; 
>>> if different or not found, then save/update it.
>>>
>>> Thanks,
>>> Peter
>>>
>>> P.S. I was looking through other postings that talked 
>>> about Session.Merge():
>>> - https://groups.google.com/forum/#!searchin/nhusers/
>>> saveorupdate$20merge/nhusers/6_8uwwl5KX4/11Pef_FreXgJ
>>> - http://stackoverflow.com/questions/4725785/stop-
>>> hibernate-from-updating-collections-when-they-have-not-changed
>>>
>>> ...and I thought Merge() would do what I needed.  
>>>
>>> But reading some more, I see that Merge is really more about whether the 
>>> instance is already associated with the current session.  (Merge will... 
>>> "Copy the state of the given object onto the persistent object with the 
>>> same identifier. If there is no persistent instance currently associated 
>>> with the session, it will be loaded.")
>>>
>>> So I'm confused - will Merge() do what I need?  Or am I looking in the 
>>> wrong place?
>>>
>>  -- 
>> You received this message because you are subscribed to the Google Groups 
>> "nhusers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to [email protected] <javascript:>.
>> To post to this group, send email to [email protected]<javascript:>
>> .
>> Visit this group at http://groups.google.com/group/nhusers.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"nhusers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/nhusers.
For more options, visit https://groups.google.com/d/optout.

Reply via email to