You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
In some valid specs, the use of anyOf, oneOf, nullable, and/or type as a list, can cause generated class names to have unnecessary suffixes (and, sometimes, for spurious extra copies of classes to appear). These problems seem to all ultimately come from the behavior of UnionProperty.
The problem cases are all included in the attached specs files. Looking at the code generated from these specs—
in both 3.0 & 3.1:
ExampleModel.nullableObjectWithOneOf correctly has the type Union[MyObject, None, Unset].
ExampleModel.inlineNullableObject generates a model class called ExampleModelInlineNullableObjectType0. It should be just ExampleModelInlineNullableObject, since there are no other named types for this property.
Similarly, the MyEnum schema, which is a nullable enum, generates the class MyEnumType1 even though there is no Type0.
The MyEnumWithExplicitType schema is the same as MyEnum except it specifically indicates type, and the result is a bit wilder: it generates enum classes MyEnumWithExplicitTypeType1, MyEnumWithExplicitType2Type1, and MyEnumWithExplicitType3Type1, all of which are exactly the same.
only applicable to 3.1:
ExampleModel.nullableObjectWithExplicitTypes, which is the same as nullable_object_with_one_of except that it also (unnecessarily, but validly) specifies type: ["object", "null"], also works correctly.
ExampleModel.one_of_enums_with_explicit_types, which combines a string enum with an int enum and specifies `type: ["string", "integer"], has the problem where three classes are created for each enum.
eli-bl
changed the title
spurious classes are generated when an enum is nullable
union types and nullables can create unnecessary class suffixes (and related problems)
Sep 14, 2024
Describe the bug
In some valid specs, the use of
anyOf
,oneOf
,nullable
, and/ortype
as a list, can cause generated class names to have unnecessary suffixes (and, sometimes, for spurious extra copies of classes to appear). These problems seem to all ultimately come from the behavior ofUnionProperty
.The problem cases are all included in the attached specs files. Looking at the code generated from these specs—
in both 3.0 & 3.1:
ExampleModel.nullableObjectWithOneOf
correctly has the typeUnion[MyObject, None, Unset]
.ExampleModel.inlineNullableObject
generates a model class calledExampleModelInlineNullableObjectType0
. It should be justExampleModelInlineNullableObject
, since there are no other named types for this property.MyEnum
schema, which is a nullable enum, generates the classMyEnumType1
even though there is noType0
.MyEnumWithExplicitType
schema is the same asMyEnum
except it specifically indicatestype
, and the result is a bit wilder: it generates enum classesMyEnumWithExplicitTypeType1
,MyEnumWithExplicitType2Type1
, andMyEnumWithExplicitType3Type1
, all of which are exactly the same.only applicable to 3.1:
ExampleModel.nullableObjectWithExplicitTypes
, which is the same asnullable_object_with_one_of
except that it also (unnecessarily, but validly) specifiestype: ["object", "null"]
, also works correctly.ExampleModel.one_of_enums_with_explicit_types
, which combines a string enum with an int enum and specifies `type: ["string", "integer"], has the problem where three classes are created for each enum.OpenAPI Spec Files
3.0: https://gist.github.com/eli-bl/7bea406525fb3b1452a71781ada5c1c0
3.1: https://gist.github.com/eli-bl/c03c88eb69312053e0122d1d8a06c2a0
Desktop (please complete the following information):
The text was updated successfully, but these errors were encountered: