Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support Composed Constraints #4799

Open
michael-arndt-gcx opened this issue Nov 26, 2024 · 2 comments
Open

Support Composed Constraints #4799

michael-arndt-gcx opened this issue Nov 26, 2024 · 2 comments

Comments

@michael-arndt-gcx
Copy link

Jakarta Bean Validation allows to compose constraints as described in 3.3. Constraint composition.

I'd like to implement basic support for this. My idea would be to add a preprocessing step to

protected void applyBeanValidatorAnnotations(BeanPropertyDefinition propDef, Schema property, Annotation[] annotations, Schema parent, boolean applyNotNullAnnotations) {

which flattens all Annotations. That means: when an annotation is annotated with javax.validation.Constraint, all its annotations are treated as if all annotations are on the annotated element.

This has been requested as feature e.g. in springdoc/springdoc-openapi#1486

wudip added a commit to wudip/swagger-core that referenced this issue Dec 1, 2024
@wudip
Copy link

wudip commented Dec 1, 2024

Hi @michael-arndt-gcx, I tried to extend your idea into a PR since this issue bugs me for some time: #4801 It works for me locally.

@michael-arndt-gcx
Copy link
Author

Hey, really nice to see someone pick this up! I've also started, but then it came clear I'll loose my day-job, so other things take priority 😅

One problem with mapping bean validation to OpenAPI is that Bean Validation allows an arbitrary number of constraints, even of the same type, whereas OpenAPI allows only up to one. So for example you could add 100 different minimum value constraints. In Bean Validation, they would all be evaluated, and every violated constraint would be reported.
(This also makes workaround like copying the same validations from the compound to the field – what we did for semantic reasons – a bit wonky)

That makes the adoption a bit less trivial, if @Min(5) and @Min(3) is there, then 3 should take precedence.

For Pattern it's worse. In theory we could create the conjunction of multiple patterns with a positive lookahead (e.g. ^[1-6]+$ and ^[4-9]+$ would become (?=^[1-6]+$)^[4-9]+$). But that only works correctly when all patterns are fully anchored. So maybe add some kind of WARN log for this?

What do you think?

Here's my work-in-progress, just for reference #4811

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants