Skip to content

Support enum Schemas #102

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
dbanty opened this issue Jul 22, 2020 · 1 comment · Fixed by #122
Closed

Support enum Schemas #102

dbanty opened this issue Jul 22, 2020 · 1 comment · Fixed by #122
Assignees
Labels
✨ enhancement New feature or improvement
Milestone

Comments

@dbanty
Copy link
Collaborator

dbanty commented Jul 22, 2020

Is your feature request related to a problem? Please describe.
Currently anything provided in a schema is assumed to be an object with properties. This means if an Enum is declared in schemas to be shared across endpoints (as is the case in the latest FastAPI/Pydantic), you get an empty dataclass as your enum instead of an actual Enum.

Describe the solution you'd like
Declaring an Enum in a schema should work exactly the same as declaring an Enum in-line for an endpoint. The output should be an Enum in the generated client.

Additional context
A simple way to see the problem is to regenerate the golden-master for end to end tests with the latest FastAPI/Pydantic.

@dbanty dbanty added the ✨ enhancement New feature or improvement label Jul 22, 2020
@dbanty dbanty added this to the 0.5.0 milestone Jul 23, 2020
@dbanty
Copy link
Collaborator Author

dbanty commented Jul 24, 2020

This is going to be a decent amount of work. Currently the components/schemas section of the OpenAPI document is parsed by Models.build which assumes that everything inside it will become a dataclass. Conversely, Enums are registered globally whenever an Enum property is created. This is a pretty icky way of doing things anyway.

Better, I think, will be to more properly have a "schemas" dictionary of name -> Property (which I think needs a new name?). Then Model should become a type of property like everything else, just one that will eventually be represented like a dataclass.

Processing "components/schemas" should register properties (probably just Enum/Model but I think any Schema is allowed here) in the dictionary. That dictionary should then be passed into EndpointCollection.from_data (the thing that parses "paths") so that any inline enums or objects can properly be registered into the same collection (functionally, not globally).

When that's done, we can loop back through and sort out the schemas/references that need to be generated into Enums/dataclasses.

@dbanty dbanty assigned dbanty and emann and unassigned dbanty Aug 4, 2020
emann added a commit to emann/openapi-python-client that referenced this issue Aug 4, 2020
dbanty pushed a commit that referenced this issue Aug 5, 2020
* Added support for enum schemas. Closes #102
Co-authored-by: Ethan Mann <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
✨ enhancement New feature or improvement
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants