Skip to content

Example object in Schema is always of String type #420

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

Closed
dmi3coder opened this issue Apr 17, 2020 · 2 comments
Closed

Example object in Schema is always of String type #420

dmi3coder opened this issue Apr 17, 2020 · 2 comments

Comments

@dmi3coder
Copy link

dmi3coder commented Apr 17, 2020

The original issue was posted here: smallrye/smallrye-open-api#300
I have a very simple User object where I have id field of type integer. I added example with specifying the type

public class User {

    @Schema(type = SchemaType.INTEGER, example = "1000")
    private Integer id;
... constructor, getters, and setters omitted
}

This generates a schema with an example as a string

    User:
      type: object
      properties:
        id:
          format: int32
          type: integer
          example: "1000"

Because of this in e.g Swagger UI when I'm prompted to fill in the example I have string type, users can think that it's mandatory to wrap integer into double-quotes.

By OpenAPI, an example can be any type of object(e.g integer, string, number), but currently, there's no way to specify that you want to parse this value into the required format. As I understand implementation doesn't know whether to parse this value or use it as a string.

As @MikeEdgar suggested: "Maybe the change could be to add to @ExampleObject a property boolean parseValue and support using that annotation from @Schema"

@MikeEdgar
Copy link
Contributor

@dmi3coder - we discussed this in the Microprofile OpenAPI hangout last week and found that my suggestion to open this as a specification issue was a bit misguided. This is an implementation problem and your original issue in SmallRye is the best place to continue this discussion.

Basically, the implementation should be handling the parsing of the example string based on the type of the enclosing schema, which was your original thought. We would only want to go down the path of using @ExampleObject if multiple examples are necessary, and maybe not even then.

If you are in agreement, please go ahead and close this issue and we can continue working this as a change in smallrye-open-api.

@dmi3coder
Copy link
Author

@MikeEdgar sounds great, thank you

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

No branches or pull requests

3 participants