Re: [bv-dev] TraversableResolver and JPA
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(a)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(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev