[bv-dev] TraversableResolver and JPA

[Gunnar Morling]

Seems the best and only thing we could do is to talk with JPA spec folks
and suggest to add a method to PersistenceUtil for checking wether a given
class is an entity type or not. I'd hope JPA is open for such additions
given the move to EE4J :)

--Gunnar


2017-10-09 17:44 GMT+02:00 Guillaume Smet <guillaume.smet at gmail.com>:

> Yes, the PersistenceUtil API is pretty basic and you can't do much about
> that.
>
> And you're right about Hibernate not being the only JPA provider in
> the classpath. I didn't think of this case.
>
> What would be possible is to do what WebLogic did ie have a specific
> TraversableResolver when the validation is triggered by ORM directly.
> It wouldn't help the case of the other validation calls though.
>
> On Mon, Oct 9, 2017 at 5:00 PM, Emmanuel Bernard <emmanuel at hibernate.org>
> wrote:
> > If you can detect that this is not an entity class, then you could cache
> this information in a bounded cache (weak key). It should help a lot. But I
> don't think PersistenceUtil has such API and if you use Hibernate specific
> APIs, you are never guaranteed than you are the only JPA provider in the
> classpath unless you look for them or the app server tells you. Tricky
> optimisation.
> >
> >> On 9 Oct 2017, at 16:24, Guillaume Smet <guillaume.smet at gmail.com>
> wrote:
> >>
> >> OK so we can't really do anything about it.
> >>
> >> I tuned HV to be a bit more efficient and avoid an additional cache
> >> lookup on cascade with the JPA TraversableResolver (the isCascadable()
> >> method always returns true so we don't need to cache it).
> >>
> >> It might be a good idea to discuss with the ORM people to see if we
> >> can be a bit more efficient in the Hibernate case. There is a TODO in
> >> our code about introducing some specific optimizations.
> >>
> >> --
> >> Guillaume
> >>
> >> On Mon, Oct 9, 2017 at 11:56 AM, Emmanuel Bernard
> >> <emmanuel at hibernate.org> wrote:
> >>> The reason was to be able to validate entities outside of explicit JPA
> calls and not cross the lazy loading boundaries.
> >>> It would become a very big overhead to load data from the database for
> validation.
> >> _______________________________________________
> >> beanvalidation-dev mailing list
> >> beanvalidation-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
> >
> >
> > _______________________________________________
> > beanvalidation-dev mailing list
> > beanvalidation-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20171018/938a2fd0/attachment.html