Skip to content
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

Can we remove the hidden classes from the OpenAPI specification? #134

Open
chriswmackey opened this issue May 12, 2020 · 2 comments
Open
Labels
discussion Discussions about where to take the development enhancement New feature or request question Further information is requested

Comments

@chriswmackey
Copy link
Member

I just checked the most recent redocly rending of the schema and saw that a number of hidden classes are appearing in the specification:
image

Because these objects should never appear in a submitted Model, it intuitively feels like they should be excluded from the schema but I don't know if @MingboPeng or @mostaphaRoudsari need them for a specific purpose.

So I am opening this issue to ask can/should we remove them?

@chriswmackey chriswmackey added enhancement New feature or request question Further information is requested discussion Discussions about where to take the development labels May 12, 2020
@mostaphaRoudsari
Copy link
Member

mostaphaRoudsari commented May 12, 2020

Hey @chriswmackey, yes. Ideally they should not be there.

Here is what's happening: We have two API specification documents. One is called model.json and the other one is model_inheritance.json.

The first one is generated by Pydantic and has minimum amount of modifications from us. The schema that is generated from Pydantic doesn't have any dependencies/inheritance between the objects. As a results it only load the objects that user will need to see. In other words no private classes.

The second one is the one that we generate based on the openapi specification that is generated by Pydantic. It uses inheritance and because of that it includes all the objects/classes including the baseclasses. The main reason that we started generating this version was to use it for dotnet SDKs.

Before adding the Radiance properties objects we were using the first one (model.json) for the viewer and the second one (model_inheritance) for dotnet builds. But after adding the Radiance properties the viewer couldn't handle the recursive objects and the model.json file would not show up in the viewer. I even tried to bundle the page locally and it was unsuccessful.

Luckily, it renders the one with inheritance! That's why I switched the viewer to use the one with inheritance until we find a better way. We either have to fix the viewer or create a minimal case and report the issue for them to fix it. Both of them will be time consuming. As a result I just left it as is. I agree that they better not to be there but if someone wants to use the model schema and follows the documentation will never get to those objects.

My suggestion is to keep this issue open and change it to an enhancement item and once we get some extra time to explore the issue further or it becomes an issue for someone get back to it and get it fixed. Let me know what you think.

@chriswmackey
Copy link
Member Author

Sounds good, @mostaphaRoudsari , and thank you for the explanation. We will keep this issue open, then.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discussion Discussions about where to take the development enhancement New feature or request question Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants