Add support for extra tags and custom types #105

Activity

1. LucasRoesler commented on Aug 2, 2023

   

   LucasRoesler

   on Aug 2, 2023

   Member

   More actions

   I am not opposed to this, but would love to see a more complete example (sample openapi spec and desired generated code) so that I better understand your use case.

   The main example I immediately think of is trying to map to existing types from a third party package. The first that comes to mind is geojson. But, this adds a lot of complexity and moves a bit away from the original goal of this project which is "schema first, then types". I could see something like x-go-type leading to bugs in applications because the API spec doesn't actually match the Go type being used.

   Having said all of that, I still want to hear more about the exact issue you have and types you are currently trying to use.
2. taythebot commented on Aug 2, 2023

   

   taythebot

   on Aug 2, 2023

   Author

   More actions

   I see your point about the x-go-type and how schema should be first. But the x-oapi-codegen-extra-tagswould still be useful.

   In my case I'm trying to use Playground Validator instead of the built in ozoo validation. In order to use it, I need to specify the validation rules inside the struct tags.

   OpenAPI

   order:
     type: string
     enum:
       - asc
       - desc
     x-go-type: string
     x-oapi-codegen-extra-tags:
       validate: required,oneOf=asc desc

   Generated Code

   Order string `json:"order,omitempty" mapstructure:"order,omitempty" validate:"required,oneOf=asc desc"`

   Even outside of Playground validator, it would still be useful as a lot of other Golang validation libraries also rely on struct tags. Giving the user freedom to choose what validation library to use would also help adoption.
3. LucasRoesler commented on Aug 7, 2023

   

   LucasRoesler

   on Aug 7, 2023

   Member

   More actions

   I am curious, the models already come with validation. Your example uses required and oneOf=asc desc and both cases are possible in the current implementation. Is there another struct tag you want to add besides validation?

   Whenever possible, we have tried to use plain OpenAPI and default to the built-in features as much as possible, translating them to Go as good as possible. The intent the spec should be sharable with other teams using other languages. Adding more x- fields means adding features that other generators are unlikely to ever adopt which would mean drift and potentially conflicting implementations. Validation is an area that is already mostly covered by the OpenAPI spec and we would prefer to not add a new extension for it.