HV-2004 Add constraint initialization payload #1587
Conversation
|
and use it to cache patterns in the predefined factory Signed-off-by: marko-bekhta <[email protected]>
marko-bekhta
force-pushed
the
feat/HV-2004-add-constraint-initialization-payload
branch
from
b5a14d2 to
c5b8c43
Compare
| * @see org.hibernate.validator.HibernateValidatorConfiguration#addConstraintValidatorInitializationPayload(Object) | ||
| */ | ||
| @Incubating | ||
| <C> C getConstraintValidatorInitializationPayload(Class<C> type); |
There was a problem hiding this comment.
It's not a payload thout, is it? More of a shared/reusable/cached context?
Also I wouldn't include ConstraintValidator in the name considering we're in HibernateConstraintValidatorInitializationContext already.
| <C> C getConstraintValidatorInitializationPayload(Class<C> type); | |
| <C> C getCached(Class<C> type); |
or
| <C> C getConstraintValidatorInitializationPayload(Class<C> type); | |
| <C> C getCache(Class<C> type); |
Alternatively if you really intend a cache here, you could make this closer to what @Sanne added to Hibernate ORM recently: https://github.com/hibernate/hibernate-orm/blob/bfa7102e228887a7f9e45211a7b051e5b1791215/hibernate-core/src/main/java/org/hibernate/internal/util/cache/InternalCacheFactory.java#L14 . Which would allow integrators to plug a custom cache provider, like Caffeine, which is known to have very good performance.
There was a problem hiding this comment.
That being said if the cache is only there for bootstrap, and gets cleared/deleted once bootstrap is finished, using Caffeine is probably overkill...
There was a problem hiding this comment.
yeah ... naming is hard 😔 🙂
Yes, it's closer to shared context. The other thought that I had about this: if we were always running the validator in the CDI context and with the predefined scope (i.e. all metadata is built at boot and not dynamically at runtime), I'd think of PatternConstraintInitializer as a bean that we inject into the PatternValidator, and the scope of such beans would be the init phase of the validator factory... but we aren't always running in CDI 🙈
|
https://hibernate.atlassian.net/browse/HV-2004
I didn't want to have some hardcoded cache for patterns within the pattern constraint validator impl itself. Hence I was thinking that leveraging something similar to what we have for validation with payload could work.
initialization payload would be available to any constraints. As for patterns and their caching, limiting it to the predefined scope makes sense as we have all constraints initialized and can clear out the cache.
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on licensing, please check here.