Hi,
I add relationship to an entity persist it and then check that it has added and it fails.

The relationship is called children and it is on the entity Person.

The relationship in Person as:

private List <Person> children = new ArrayList();

@ManyToMany(cascade=CascadeType.REFRESH)
public List<Person> getChild() {
return children;
}

Here is my test code

Person person = new Person();
Person child = new Person();
List <Person> children = new ArrayList();
em.persist(person);
em.persist(child);

children.add(child);
person.setChildren(children);
em.getTransaction().commit();

// now reread and test
em.refresh(person);
System.out.println("will print true if equal, person.getChildren().equals(children));


and false is outputted even though the contents of both Lists are the same.

On inspection of the hibernate code, when .equals() is called it delegates to:

org.hibernate.collection.PersistentBag.equals()

which delegates to java.lang.Object, so only the object references are compared which then fail.

I would have thought since I declared the relationship as an ArrayList, the equality check should work the same way, i.e. checking contents.

This does not appear to be case,

Comments, thoughts welcomed...

check the wiki area for equals/hashCode implementation.

Thanks for that.
I checked the article and it is more to do with single entity not relationships.

I looked at the code for org.hibernate.collection.PersistentBag.equals() and it just delegates to java.lang.Object.
So because of this I would guess that it is irrelevant if the .equals() is implemented in the POJO.

What's interesting is that there is another equals commented out

/*public boolean equals(Object other) {
read();
return bag.equals(other);
}

public int hashCode(Object other) {
read();
return bag.hashCode();
}*/

Is there any plans to update PersistenceBag.equals()?

interesting, that's a choice I have been arguing with Gavin when I joined Hibernate. As you can see I lost :-)

Fair enough. I would think it should there of course :)

emmanuel, I tried to locate your/Gavin arguments about why bag does not implement equals/hashCode as an ordinary collection here, but that is not evident for me. Is it worse opening a bug in JIRA?

Relative links:

• idbag, equals() and hashCode()
• Add a note about equals() and hashCode() on bag/idbag to the documentation

Pretty old topic, but it's at the top of the Google results for "hibernate persistentbag equals" so I thought I'd add my two cents and see if we can get a response/status update.

If PersistentBag implements the List interface, this is a bug. Plain and simple. A List is an ordered collection of objects and has a well defined equals operation. This unexpectedly fails that check.

If PersistentBag doesn't implement a List interface, feel free to implement equals by some other standard. I'd expect it to behave like a Set at that point, but I guess it would depend on implementation.

Indeed, it does, otherwise Hibernate objects are not injectable into POJOs:

Feel free to vote for HHH-5409: even though the bug is very old, nobody (except real gurus) really cares.

Link for the lazy:

https://hibernate.onjira.com/browse/HHH-5409

This seems like some low-hanging fruit that would have saved me (and surely others) some headache.

Hey dude.. I wanna check this link, but it can't open..Recheck it.

The link opens just fine. Try again, perhaps temporary internet problems.

Why would you want to include a List in a equals/hashCode comparison for a root entity? This is a wrong approach.

Equality should be based on the underlying table record unicity constraint. Ideally, you should have a natural key in every database table like a SSN, email address, domain name, UUID.

Sometimes, you don't have a natural id, but then you still have the primary key. Contrary to popular belief, you can use the PK for equals/hashCode, you just have to make sure that hashCode renders a constant value for every entity state transition.

If you worry about hashCode performance, then you should know that a persistent collection is not meant to store large amounts of data. So, prior to having the hashCode as a real bottleneck (as depicted in Effective Java), you'd have to fetch the collection, and the fetching tons of data is way more costly anyway. If that's the case, you are better off using a query instead.