Re: [hibernate-dev] Entity implementation of equals()
Generally speaking an `#equals` method would not allow subclasses to
match. For entity mappings specifically I this it is generally considered
kosher to allow subclass matching in `#equals`. Interestingly, when
generating `#equals` overrides through IntelliJ it even asks specifically
whether subclasses should be allowed to match. In fact it mentions (or
used to mention) Hibernate specifically wrt proxies in the dialog.
And it's actually required (as you found) if you want to use Hibernate's
proxy-based lazy loading.
However, this is a case with a MappedSuperclass and specifically a
MappedSupperclass that is I guess shared amongst multiple root entities.
So here the allowance of subclasses is not really feasible and relying on
any kind of equality checking defined on the MappedSuperclass is not going
to work
On Tue, Aug 27, 2019 at 6:49 PM Gail Badner <gbadner(a)redhat.com> wrote:
Hi,
I'm looking into the impact of HHH-13590.
In the test for HHH-13590, I see that the mapped superclass entity defines
equals() as:
@Override
public boolean equals(Object o) {
if (this == o) return true;
if (o == null || getClass() != o.getClass()) return false;
...
}
Due to the bug:
* this is a Project instance;
* o is a HibernateProxy with target == this.
Because the getClass() != o.getClass(), false is returned, and that
ultimately causes the test to fail.
The fix for HHH-13590 results in comparing a Project instance with itself
(not the proxy).
I see that the documentation has a similar implementation of equals() in
"Example 111. Natural Id equals/hashCode" of [1].
In general, is it OK for equals() to require both instances to be of the
same class?
Thanks,
Gail
[1]
https://docs.jboss.org/hibernate/orm/5.4/userguide/html_single/Hibernate_...
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev