Closed Szer closed 2 years ago
looks good, my only worry would be with API that relied on bad input being null instead of an error, it would be good to have a way to confiure that per type with an annotation.
If the ktype retains the annotations properly it would be good to add an annotation, like @IgnoreInvalid MyEnum
that parses null in the case of bad values.
If it requires an overhaul we'll leave it at that.
Make sense for that behaviour to be opt-in, I look into it.
So I've added opt-in behaviour to this feature. Alternative implementations were
Add new field to ParameterModel
. That also would require changes to QueryParam, HeaderParam, PathParam
Pros: These annotations already exist and they could be placed freely on types you don't own
Cons: A lot of changes required in builders.
Add new annotation which will tell that this enum needs strict parsing Pros: Really easy to implement Cons: You have to own the type to annotate with new annotation. Can't put it on 3rd party enums
I've decided to go with the second approach just because I was overwhelmed by amount of changes needed for the first approach.
So in this PR I've added new annotation StrictEnumParsing
which presence will change behaviour of EnumConverter
Because it is new annotation, no behaviour change for existing code.
@Wicpar added opt-in behaviour
@Wicpar gently reminding about this PR :)
It fixes https://github.com/papsign/Ktor-OpenAPI-Generator/issues/111 with throwing
OpenAPIBadContentException
on parsing wrong value.This validation won't add anything to RouteSelectors, so you have to manually catch error via StatusPage ktor feature to show desired StatusCode and message to the user. Which I think totally fine because current code throws
OpenAPIRequiredFieldException
on omitting non-nullable query parameter, so this is the same behavior.Behavior change
Assuming we have enum parameter with name
type
and valid values:[VALID]
Nullable
BEFORE
AFTER
NON nullable
BEFORE
AFTER
ADDED 20 Oct
Added opt-in behaviour to this feature. Alternative implementations were:
Add new field to
ParameterModel
. That also would require changes to QueryParam, HeaderParam, PathParam Pros: These annotations already exist and they could be placed freely on types you don't own Cons: A lot of changes required in builders.Add new annotation which will tell that this enum needs strict parsing Pros: Really easy to implement Cons: You have to own the type to annotate with new annotation. Can't put it on 3rd party enums
I've decided to go with the second approach just because I was overwhelmed by amount of changes needed for the first approach.
So in this PR I've added new annotation
StrictEnumParsing
which presence will change behaviour of EnumConverter Because it is new annotation, no behaviour change for existing code.