|
From: <jue...@we...> - 2003-07-29 15:01:55
|
<quote> So, we make a hashCode with some smarts. First time hashcode is called, - if id is null/zero, then hashCode will forever return the same value,=20 which is the same for all class instances. Inefficient, but doesn't=20 cause Sets to barf. - but if is not-null/zero and hashCode has never been called while id=20 was null/zero, then hashCode will retun a value based on the id. This=20 means that loaded entities loaded form the db are treated efficiently. Still not that great in terms of efficiency for new entities, but=20 efficient for old entities. </quote> Interesting idea - a hashCode implementation that tracks if it has = already been called with an empty ID... So "contains" and "remove" will = work even after saving, but unfortunately only for this very instance. = Calling "contains" with a freshly loaded instance (and the previously = saved one in the collection) will still fail, as the freshly loaded = instance will return an ID-based hash code that will not match the one = in the collection. <quote> Also, there is still an issue with any collection (ie not HashSet) that=20 uses 'equals', since that is going to change when the id changes. </quote> But that doesn't matter as such a collection will just call "equals" on = *lookup*, not on *addition*. It will always find an entity, as long as = "equals" can deal with the current state. That's not the case with = HashSet: The hash code of an object is determined within the "add" = method, and fixed from there on. Juergen |