[hibernate-dev] HHH-12353: have getReference stick to the Java API it promises?

[Steve Ebersole]

Fun trip down memory lane :)

No one really like my proposed solution, but also no one really seemed to
dislike it enough to implement something themselves ;)

Anyway, those older discussions are a piece of the same overall discussion
that this one belongs to.  This discussion is just a specific part of it.
Sanne and I both thought that the API should just accept the interface - we
just had different opinions about how that should work in mapping and in
the impl of the call.  Neither of our suggestions is spec compliant
though.  And in this specific case I think (a) is the only real option

On Mon, Mar 5, 2018 at 8:57 AM Gunnar Morling <gunnar at hibernate.org> wrote:

> Hey,
>
> It's just three and six years, respectively, since we discussed this matter
> last [1], [2] (wow, I'm feeling old somehow now ;)
>
> Detecting the situation at boot time and raising an exception early on
> would be the best.
>
> --Gunnar
>
> [1] http://lists.jboss.org/pipermail/hibernate-dev/2015-April/012520.html
> [2]
> http://lists.jboss.org/pipermail/hibernate-dev/2012-January/007629.html
>
>
> 2018-03-05 14:53 GMT+01:00 Sanne Grinovero <sanne at hibernate.org>:
>
> > Issue HHH-12353 was just reported and I have to agree it looks dodgy.
> >
> > Essentially invoking:
> >
> >  entityManager.getReference( Person.class )
> >
> > might not return a type compatible with Person, when Person is final
> > and annotated with @Proxy(proxyClass = AnotherTypeX.class), then
> > AnotherTypeX might be returned and this is not necessarily a subtype
> > of Person.
> >
> > That's ok as I understand we hardly have alternatives, but the
> > EntityManager API for getReference mandates this signature:
> >
> >  <T> T getReference(Class<T> entityClass, Object primaryKey)
> >
> > so we're not actually returning the expected type T in all
> > circumstances, confusing compilers and tooling into giving the wrong
> > suggestions.
> >
> > I see some options:
> > a# disallow using @Proxy on a final entity - seems reasonable since
> > the docs warn against pitfalls.
> > b# throw an exception on Person.class being used as parameter, as the
> > user should actually use the proxytype?
> > c# somehow have the proxy still extend the final entity?
> >
> > Option b# seems problematic as it's not obvious to users either, and
> > we would need to return a proxy reference even when there actually is
> > a managed Person instance in the current session.
> >
> > Option c# is probably unrealistic and problematic too, as it would
> > require enhancing of the final class and I guess we can't rely on that
> > consistently.
> >
> > In summary, I believe we should throw a bootstrap exception requiring
> > to remove the `final` modifier on the parent entity. Or challenge the
> > specification :(
> >
> > Thanks,
> > Sanne
> > _______________________________________________
> > 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
>