There have been some discussions here about JPA entities and which hashCode()
/equals()
implementation should be used for JPA entity classes. Most (if not all) of them depend on Hibernate, but I'd like to discuss them JPA-implementation-neutrally (I am using EclipseLink, by the way).
All possible implementations are having their own advantages and disadvantages regarding:
hashCode()
/equals()
contract conformity (immutability) for List
/Set
operations- Whether identical objects (e.g. from different sessions, dynamic proxies from lazily-loaded data structures) can be detected
- Whether entities behave correctly in detached (or non-persisted) state
As far I can see, there are three options:
- Do not override them; rely on
Object.equals()
and Object.hashCode()
hashCode()
/equals()
work- cannot identify identical objects, problems with dynamic proxies
- no problems with detached entities
- Override them, based on the primary key
hashCode()
/equals()
are broken- correct identity (for all managed entities)
- problems with detached entities
- Override them, based on the Business-Id (non-primary key fields; what about foreign keys?)
hashCode()
/equals()
are broken- correct identity (for all managed entities)
- no problems with detached entities
My questions are:
- Did I miss an option and/or pro/con point?
- What option did you choose and why?
By "hashCode()
/equals()
are broken", I mean that successive hashCode()
invocations may return differing values, which is (when correctly implemented) not broken in the sense of the Object
API documentation, but which causes problems when trying to retrieve a changed entity from a Map
, Set
or other hash-based Collection
. Consequently, JPA implementations (at least EclipseLink) will not work correctly in some cases.