6:48 p.m.
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_...
9:28 p.m.
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
10 p.m.
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).
Jan-Willem
Op 27 aug. 2019 om 22:29 heeft Steve Ebersole
<steve(a)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.
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
>
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
11:18 p.m.
Please see below...
On Tue, Aug 27, 2019 at 8:00 PM Jan-Willem Gmelig Meyling <
jan-willem(a)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(a)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(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
>>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
7:05 a.m.
There are 2 different discussions here:
1) How to implement `#equals` to account for HibernateProxy
2) How to implement `#equals` in a MappedSuperclass
These things are at odds here.
With regards to (1), as discussed above, you have to allow subclasses in
the equality comparison *if* you want to use proxy-based laziness. Is
there a specific discussion about that? Well there is, or used to be, an
entire section in the documentation about implementing `#equals` properly.
I do not remember whether it mentions this "allow subclasses"
specifically. However it is common sense given the documented way that
proxy-based laziness works.
The real problem here is that the MappedSuperclass is defined "above" the
root entities in the hierarchy and the user is trying to define the
comparison there. Allowing subclass matching there means that any entity
type would equal any other entity types, even entities in a different
entity hierarchy. E.g. say Customer and Order are both root entities and
extend a common MappedSuperclass named BaseEntity - if BaseEntity defines
`#equals` to allow subclasses to match then a Customer would equal an Order
which is clearly wrong.
As far as using getters in the `#equals` impl to account for laziness... I
do not know if it is specifically documented somewhere, but again that's
just common sense.
Note that these in particular could be handled via the new "bytecode proxy"
feature. There would be no HibernateProxy involved and access to getters
*or fields* would trigger the load. Just a thought
On Tue, Aug 27, 2019, 11:18 PM Gail Badner <gbadner(a)redhat.com> wrote:
Please see below...
On Tue, Aug 27, 2019 at 8:00 PM Jan-Willem Gmelig Meyling <
jan-willem(a)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(a)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(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
> >>
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
1947
days inactive
1948
days old
4 comments
3 participants
participants (3)
-
Gail Badner -
Jan-Willem Gmelig Meyling -
Steve Ebersole