Please see below...
On Tue, Aug 27, 2019 at 8:00 PM Jan-Willem Gmelig Meyling <
jan-wil...@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 <st...@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 <gbad...@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@lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev@lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
_______________________________________________
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
