[hibernate-dev] Entity implementation of equals()

[Gail Badner]

Please see below...

On Tue, Aug 27, 2019 at 8:00 PM Jan-Willem Gmelig Meyling <
jan-willem at youngmediaexperts.nl> wrote:

> I tend to use this.getClass().isInstance(o) and this.getClass().cast(o)
> which works even in a mapped super class on most occasions. (Assuming that
> the proxy delegates equals to a concrete target).
>

Your suggestion worked to get past the class comparison.

There is still an issue though when comparing to a HibernateProxy.

This returns false: bID.equals( that.bID).

This returns true: bID.equals( that.getbID() ).

I've never noticed this before.

Steve, is there some requirement that getters have be used to compare
properties when an entity can be lazy?


>
> Jan-Willem
>
>
> > Op 27 aug. 2019 om 22:29 heeft Steve Ebersole <steve at hibernate.org> het
> volgende geschreven:
> >
> > 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.
>

It makes sense, but I don't remember reading it. Is this documented
somewhere?

HHH-13590 specifically has to do with an entity's #equals(Object o) with o
being a HibernateProxy.

The fix unproxies the HibernateProxy, so that the argument to
#equals(Object o) is the target (not a HibernateProxy).

Thanks,
Gail

>
> > 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 at 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_User_Guide.html#mapping-model-pojo-equalshashcode
> >> _______________________________________________
> >> hibernate-dev mailing list
> >> hibernate-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>