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
The referenced objects are not relevant, they are just objects defined elsewhere in the schema, so they have already been generated.
Three model files are generated for this object, when it should be two:
'device_type` for the object itself
device_type_all_of the correctly generated inline object for the second element of the allOf list
device_type_all_of1 An incorrectly generated object containing the sensors property.
The problem is caused by the flattening process in InlineModelResolver. In the method InlineModelResolver.flattenComponents(OpenAPI) composite schema's are flattened.
I think the intention is to pull out in-line objects and make sure they exist, but it is a little bit confused, so I am not 100% certain its supposed to do something else as well.
The allOf list in the model schema is passed to flattenComposedChildren. And the list contains 3 entries
Schema<T> for the reference to device_obj_test and type null
ObjectSchema referring to the object defined in the second element of the allOf list, with no reference and type object
Schema<T> with no reference and type null, containing a schema description of the properties
The last element, with no type or reference should not be created as a component. However, its properties should be flattened, so that any in-line types that are within the property list are created. The method that does this is
There are quite a few problems embedded in this bit of code. There are several locations where new schema objects are created and the values set from the old one, not necessarily wrong, but very error prone. The method modelFromProperty creates a new object with a limited set of the values copied across, among the missing values is the type field, which probably should be copied across, it should be reviewed as to what else should be included. It also includes the flattening of the parameters making the functionality quite difficult to figure out.
There is another location this could be a problem at the end of DefaultCodegen.fromModel(String name, Schema schema) the model name s added to the CodegenModel's anyOf, oneOf and allOf lists, even though the corresponding refSchema is null. It probably wont make any difference, but it could also be an error waiting to happen.
openapi-generator version
The current build
OpenAPI declaration file content or url
N/A
Command line used for generation
N/A
Steps to reproduce
N/A
Related issues/PRs
???
Suggest a fix
To fix the problem is relatively simple, inside flattenComposedChildren, if the type and ref are null don't add it as a component.
Note, you have to use the test on the op object because innerModel doesn't copy the type field.
I have not tested it against anyOf, oneOf yet, but I have never got these options to work before anyway. I am about to run some tests against our object library to see if we can get them to work this time around.
In the short term, if it turns out to be a problem you can just flag the test against the allOfoption.
The text was updated successfully, but these errors were encountered:
Bug Report Checklist
Description
The following type of schema leads to a problem in the generation of model files.
The referenced objects are not relevant, they are just objects defined elsewhere in the schema, so they have already been generated.
Three model files are generated for this object, when it should be two:
'device_type` for the object itself
device_type_all_of
the correctly generated inline object for the second element of theallOf
listdevice_type_all_of1
An incorrectly generated object containing thesensors
property.The problem is caused by the flattening process in
InlineModelResolver
. In the methodInlineModelResolver.flattenComponents(OpenAPI)
composite schema's are flattened.I think the intention is to pull out in-line objects and make sure they exist, but it is a little bit confused, so I am not 100% certain its supposed to do something else as well.
The
allOf
list in the model schema is passed toflattenComposedChildren
. And the list contains 3 entriesSchema<T>
for the reference todevice_obj_test
and typenull
ObjectSchema
referring to the object defined in the second element of theallOf
list, with no reference and typeobject
Schema<T>
with no reference and typenull
, containing a schema description of the propertiesThe last element, with no type or reference should not be created as a component. However, its properties should be flattened, so that any in-line types that are within the property list are created. The method that does this is
There are quite a few problems embedded in this bit of code. There are several locations where new schema objects are created and the values set from the old one, not necessarily wrong, but very error prone. The method
modelFromProperty
creates a new object with a limited set of the values copied across, among the missing values is the type field, which probably should be copied across, it should be reviewed as to what else should be included. It also includes the flattening of the parameters making the functionality quite difficult to figure out.There is another location this could be a problem at the end of
DefaultCodegen.fromModel(String name, Schema schema)
the model name s added to theCodegenModel
'sanyOf
,oneOf
andallOf
lists, even though the correspondingrefSchema
isnull
. It probably wont make any difference, but it could also be an error waiting to happen.openapi-generator version
The current build
OpenAPI declaration file content or url
N/A
Command line used for generation
N/A
Steps to reproduce
N/A
Related issues/PRs
???
Suggest a fix
To fix the problem is relatively simple, inside
flattenComposedChildren
, if the type and ref arenull
don't add it as a component.Note, you have to use the test on the
op
object becauseinnerModel
doesn't copy the type field.I have not tested it against
anyOf
,oneOf
yet, but I have never got these options to work before anyway. I am about to run some tests against our object library to see if we can get them to work this time around.In the short term, if it turns out to be a problem you can just flag the test against the
allOf
option.The text was updated successfully, but these errors were encountered: