[bv-dev] TraversableResolver and JPA

[Emmanuel Bernard]

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.

> On 6 Oct 2017, at 16:13, Guillaume Smet <guillaume.smet at gmail.com> wrote:
> 
> Hi,
> 
> A user of Hibernate Validator reported an interesting case here:
> https://hibernate.atlassian.net/browse/HV-1489 .
> 
> The fact is that a method implemented in WebLogic is suboptimal but I
> think there is an interesting point here anyway.
> 
> In the spec, we say that when we find a JPA implementation in the
> classpath, we enable the JPATraversableResolver. This adds an overhead
> even for unmanaged entities as there is no way to tell if an object is
> a managed entity or a plain bean.
> 
> In EclipseLink, they override the traversable resolver in the context
> when validating the object on persist and I think it might be good
> idea: their JPA resolver is only used when persisting entities and
> when other objects are validated, the default traversable resolver is
> used - in the case of our user, it uses our JPATraversableResolver
> which leads to the issue he reported.
> 
> There is another advantage to this approach: the TraversableResolver
> is in the JPA implementation so it can use optimized calls to internal
> classes, instead of relying on the JPA API.
> 
> The problem with such an approach is that the user can't override the
> traversable resolver set by the JPA provider.
> 
> There is another trade-off: if the user tries to validate an entity
> outside of the JPA persist listener, it won't use the specific JPA
> resolver.
> 
> I wasn't there when this section was added so I'm not sure what was
> exactly the rationale for it.
> 
> I think we might have underestimated the overhead of our approach. We
> have a cache but the cache is per validation call so if you end up
> validating each object only once per call (and it's probably the most
> common case), the cache doesn't bring anything to you (except an
> additional overhead).
> 
> -- 
> Guillaume
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev