2011/11/30 costa <[email protected]>: > After more digging, here is what the MS documentation says (http:// > msdn.microsoft.com/en-us/library/xfhwa508.aspx): > > The speed of retrieval depends on the quality of the hashing algorithm > of the type specified for TKey. > As long as an object is used as a key in the Dictionary<TKey, TValue>, > it must not change in any way that affects its hash value. Every key [...] > > The key should be immutable, but in the NH case the items added to the > set are not immutable because as soon as they are persisted their ids > change. > I am using NH 3.1.0. I wonder if this is still a problem in NH 3.2.0. >
Yes, the violation is towards the contract of Dictionary, not GetHashCode(). Implementing Equals() and GetHashCode() is tricky. This is not a bug in NHibernate that can be "fixed". In most of my own code I haven't had the need to compare entities outside a session, which means I can avoid overriding these methods, and just rely on reference equality (except for immutable value objects, which because of their immutability pose no problem either). Another approach is to try to find an immutable business key/equality (set via the ctor) for the object and base Equals() and GetHashCode() on that. You can still use a surrogate key as primary key. Yet another possibility is to assign a new Guid to each entity in its ctor, which is persisted, and remains constant for that instance through all time. /Oskar -- 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.
