Menu
I have been trying to reason about the best way to handle whether it is generally good practice to implement hashcode and equals on entities (I mean entity in the general sense but in most cases it will be a JPA entity).
In Chapter 24 of the Hibernate manual http://docs.jboss.org/hibernate/core/3.3/reference/en/html/best-practices.html it says this...
Identify natural keys for all entities, and map them using . Implement equals() and hashCode() to compare the properties that make up the natural key.
It makes sense to have .equals and .hashcode include only these natural keys but what if you have more than one instance of the same entity (same natural id thus same hashcode)? It seems like this practice could have subtle implications elsewhere in your application. Has anybody tried this before on a large scale?
327
Java hashCode() An object hash code value can change in multiple executions of the same application. If two objects are equal according to equals() method, then their hash code must be same. If two objects are unequal according to equals() method, their hash code are not required to be different.
"You only need to override equals() and hashcode() if the entity will be used in a Set" is completely enough if some fields identify an object, and so you don't want to rely on Object. equals() to identify objects.
The hashcode() method returns the same hash value when called on two objects, which are equal according to the equals() method. And if the objects are unequal, it usually returns different hash values.
I've tried this before on a large scale (or at least in an application that heavily uses hibernate). It's a good idea.
It makes sense to have .equals and .hashcode include only these natural keys but what if you have more than one instance of the same entity (same natural id thus same hashcode)? It seems like this practice could have subtle implications elsewhere in your application.
This is what it's meant for. You typically want multiple instances of the same entity to succeed when comparing .equals, and yes, it has implications elsewhere. IMO those implications are that things would work as expected.
128
There are times when you want Equals to compare all properties and times when you want Equals to be just the key. We've had a lot more success using helper classes that are explicit so there isn't ambiguity as to what's being compared.
ByKeyComparer.Equals...
ByPropertiesComparer.Equals...
or
Entity1.EqualsByKey...
Entity1.EqualsByProperties...
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
