[REQ][python] Improve generated new input type for anyOf schema

[Marcelo00]

[REQ][python] Improve generated new input type for anyOf schema

[spacether]

The code generation is functioning as expected here. The anyOf refs are not known as possible types. For them to be known they would have to be examined at one higher schema level and compared against type info. Currently the generation only knows about input and output types for array and object, types defined in type, and ref only. Because anyOf is not analyzed for type info, the only info comes from absent type info which allows any type.

If you want different functionality here, please consider filing a PR with thorough test cases.

[spacether]

Also, should your anyOf be a oneOf so it matches only one of those schemas rather than one or more?

[Marcelo00]

Thanks for the information. Is it possible to have a short meeting or could you point out the necessary steps for such functionality? We would like to invest some time to add such feature as our use case prefers to work with these classes and it would be nice to have proper type hints. However, we cannot really judge how long it may take.

I would also assume that this behavior also occurs with other modifiers like oneOf. Is it correct?

Also, should your anyOf be a oneOf so it matches only one of those schemas rather than one or more?

You are right. Our openAPI.yaml is also auto-generated which sometime causes semantically wrong specification like this.

[spacether]

Adding this is non-trivial.
In the latest version of the generators, returned instances only subclass one class. So to do this one would need to:

• perhaps generate interfaces for all object types and have the object output classes implement them
• accumulate type + interface/dict output class info from all subschemas
• for use cases like this, the code will know from introspecting the calculated type constraints that only dicts are allowed. And we know that the oneOf interfaces or output types are allowed

Doing this is difficult because any number of keywords can exist in the same schema including:

• type
• oneOf
• allOf
  etc and type and interface information need to be gathered from them and correctly combined

So a new CodegenSchema field that could store this may look like typeToInterfaces: Map<String, List>
Interfaces can come from refed locations so one would need to store the ref location and the name of the generated interface class. Some examples:
typeToInterfaces = {"string": null, "boolean": null} # fora a schema that allows strings and numbers
typeToInterfaces = {"object": [{SingleValueClassificationAttributeInterface, MultiValueClassificationAttributeInterface}]} # for your use case with oneOf two object types
This property would need to be added to CodegenSchema.

When are you free to discuss this this week and next week?