Repository navigation
Advanced validation support #143
Description
Hi, thanks for the great project!
I have a question regarding request params object validation.
For example I have a request with 2 dates like this:
PeriodRequest:
type: object
properties:
start:
type: string
format: date
end:
type: string
format: dateand want to validate that start doesn't exceeds end.
One option is to use custom Bean Validation constraint annotation:
// here @StartEndConstraint
@GetMapping(...)
Collection getResponse(
@Valid
// or here @StartEndConstraint
PeriodRequest r
);
But I can't do it because Api interface above is generated and at the same time i can't put annotations on the implementation class:
javax.validation.ConstraintDeclarationException: HV000151: A method overriding another method must not redefine the parameter constraint configuration
As I understand the only solution is to switch to the not generated pojo and use annotation on it:
map:
types:
- type: PeriodRequest => my.not.generated.PeriodRequest
But that's undesirable solution because of the potential discrepancy between validation described in api.yaml and in code.
Are there any other options to solve this problem?
May be to have some annotation mapping features would be a better solution, something like:
map:
types:
- type: PeriodRequest annotate my.validation.StartEndConstraint
Thanks in advance!
Activity
hauner commentedon Jul 28, 2022
I fear there is currently no way to add additional annotations except skipping the generated type.
I'm fine with adding it. It will add a bit of flexibility.
It is just a matter of choosing the right path ;-)
The simple path will only allow custom annotations in context of bean validations. The bean validation code already handles annotations so it would be "just" a matter of providing the info to it (with something like your suggestion above).
More complex one would allow custom annotations independent of bean validation. More flexibility, but I'm not sure it is worth implementing. It would have bean nice maybe once or twice. ;-)
toronik commentedon Jul 29, 2022
I'm not feeling that I'm in a position to decide on the right path =)
but "the simple path" seems more preferable to me from the pragmatical perspective: as I understand it's simpler to implement and covers specific and very typical problem (in contrast to rare and imaginary ones).
hauner commentedon Jul 29, 2022
Was more a question to myself ;-)
.. but you are right. I prefer the first path too :-)
openapi-processor/openapi-processor-spring#143, read annotation mapping
openapi-processor/openapi-processor-spring#143, write additional anno…
openapi-processor/openapi-processor-spring#143, write additional anno…
#143, updated documentation
hauner commentedon Sep 7, 2022
have something running, somehow went for the more general approach. :-)
the mapping looks like this:
Foois the OpenAPI object, and the mapping will add@Sumto aFooparameter of an endpoint method:I think, I will add the following variation
to add the annotation to the generated
Fooclass:openapi-processor/openapi-processor-spring#143, write additional anno…
openapi-processor/openapi-processor-spring#143, add sample
#143, updated documentation
#143, updated documentation
#143, updated documentation
#143, updated documentation
openapi-processor/openapi-processor-spring#143, new mapping schema