when Hashcode and Equals implementation is required under hibernate?

Question

A per this Link

The gist of it is you only need to worry about it if your entity will be part of a Set(condition 1) or/And if you're going to be detaching / attaching its instances.(condition2)

As per my understanding we need only condition 1 where hashcode and equals method implementation is required

If i have a requirement where i don't want to store duplicate customer(based on customer name) or retrieve duplicate customers(for legacy data) from hibernate apis, then my understanding is storing customer under set does make sense here and it is the only scenario where we need to implement hashcode and equals method.

I do not understand how come hashcode and equal implementation helps when we are going to be detaching / attaching its instance(condition)

Update :- To confirm i tried re-attaching the detached instance like below

   person detached instance lying here for id 1// person overrides hashcode and equals method

   session = factory.openSession();
   tx = session.beginTransaction();
   person1=(Person)session.get(Person.class, 1);
   session.lock(person, LockMode.NONE);// reattaching the detached instance here
   // as per Marko Topolnik  comment i was expecting equality will be checked based on equals and hashcode 
   // method but it was done based on person id . so question is  does hashcode and equals come into picture
   // while reattaching the detached instance


   tx.commit();

Detaching and attaching relies on the definition of equality. If you reattach an instance which already exists in the session, that must be detected. Instances in a session are stored in a hashtable-based structure. — Marko Topolnik, Mar 04 '14 at 12:53
Shouldn't the reattaching be done based on object identifier? To confirm your point i re-attached person instance with lock method when already another person instance was present in session. I was expection equality will be checked based on hashcode and equal method but it was checked based on person identifier and org.hibernate.NonUniqueObjectException: was thrown. Any clue ? — user3198603, Mar 06 '14 at 16:03
Hibernate doesn't touch object Equals or hashcode methods to determine equality. All it cares about is the value of your ID field. If a database instance exists with that ID already and you try to perform anything other than an update, delete or get on that object or you try and attach an object with that ID into the session, you will get a NonUniqueObjectException. Hibernate doesn't care about your object state. — JamesENL, Mar 07 '14 at 07:07
So object hashcode and equals does not come into picture while reattaching the detached instance with session. Right? — user3198603, Mar 08 '14 at 12:27

cyprian · Answer 1 · 2015-02-21T09:39:05.947

Detaching and attaching relies on @id. Don't rely on wrong answer, the correct one is the second one from the link You provided (written by Phil).

You only need to override equals() and hashcode() if the entity will be used in a Set (which is very common) AND the entity will be detached from, and subsequently re-attached to, hibernate sessions (which is an uncommon usage of hibernate).

as hiberante documentation says:

intend to put instances of persistent classes in a Set (the recommended way to represent many-valued associations); and

intend to use reattachment of detached instances

It means that if You intend to reattach entities stored in a Set in parent entity. So only if both conditions are true at the same time, then Hashcode and Equals implementation are required for hibernate.

Also it is a good idea to implement equals and hashCode when You are using composite primary keys as it is written in composite id section

when Hashcode and Equals implementation is required under hibernate?

1 Answers1