This repository has been archived by the owner on Jun 28, 2024. It is now read-only.
Investigate improving generation of enums
#124
Comments
|
The validation problem mentioned in this issue is being discussed more specifically and in more detail on equinix-labs/metal-java#113 |
ctreatma
added a commit
that referenced
this issue
Sep 15, 2023
This enables the [`RESOLVE_INLINE_ENUMS` option for `openapi-generator@v7.0.0`](https://openapi-generator.tech/docs/customization#inline-schema-naming) to tell the generator to create dedicated models for inline enums instead of treating the inline enums as plain strings. Among other things, generating inline enums helps the SDK properly validate API responses against `oneOf` schemas in which each component schema has different enum values for the same property name. In addition to the `RESOLVE_INLINE_ENUMS` option, this also enables the `enumClassPrefix` setting. Since the constants used in each enum are defined in the same scope, we have to turn this setting on in order to avoid conflicts between different enums that include identical values. Fixes #124
|
This issue has been resolved in version 0.22.0 🎉 |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
The Metal API spec has a number of inline
enumdefinitions. There's a bug in the Go generator that treats these inlineenumsas strings instead of creating a Go enum for them: OpenAPITools/openapi-generator#2360.Should we update the official spec to move all
enumsto dedicated files undercomponents/schemas/?Something to keep in mind here is that
enumcan cause problems on response models. For example, if a new value is introduced by the API, all existing SDKs will throw a validation error when they encounter that new value, effectively breaking any integrations based on generated SDKsThe text was updated successfully, but these errors were encountered: