-
-
Notifications
You must be signed in to change notification settings - Fork 6.8k
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
Recursively search for types during import type collection in deeply nested schemas #11221
Recursively search for types during import type collection in deeply nested schemas #11221
Conversation
9011377
to
763cdb1
Compare
@ethan92429 thanks for the PR. cc @OpenAPITools/generator-core-team |
This reverts commit 6154f202a0f4db7a706fe3d61b45573581d164d4.
763cdb1
to
96a6ecd
Compare
OK - I just finished with the tests, and modularized the import collection code to make code reuse a lot easier. Should be good to go! There is definitely more work to be done in this area in terms of improving code reuse and modularity, but at least I think this is an improvement. |
@OpenAPITools/generator-core-team and @wing328 please give this a review when you get a chance! I'm hoping 🤞 that we could get it into |
modules/openapi-generator/src/main/java/org/openapitools/codegen/ComplexType.java
Outdated
Show resolved
Hide resolved
@spacether I think I've incorporated all your feedback except for the AnyType comment - I'm not sure what the implications would be there. Please advise! |
...penapi-generator/src/main/java/org/openapitools/codegen/IJsonSchemaValidationProperties.java
Outdated
Show resolved
Hide resolved
...penapi-generator/src/main/java/org/openapitools/codegen/IJsonSchemaValidationProperties.java
Outdated
Show resolved
Hide resolved
@spacether I think I incorporated all your feedback 😄 |
...penapi-generator/src/main/java/org/openapitools/codegen/IJsonSchemaValidationProperties.java
Show resolved
Hide resolved
} else if (includeContainerTypes || !(this.getIsArray() || this.getIsMap())) { | ||
// Composed types shouldn't be added directly because types like `Cat | Dog` won't have resolvable imports. | ||
imports.add(this.getComplexType()); | ||
imports.add(this.getBaseType()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This code is for our base case, can you move it above our first composedschema if?
We don't need the baseType import, that is used to describe string/int/object etc.
Unless: do you know of code that imports baseType?
if (this.getComplexType() != null) {
// Base case: referenced components need to be imported
imports.add(this.getComplexType());
}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Conversely, if I don't add baseType here, I get 130 changed sample files where key imports are removed. Some languages apparently need to import string - like in cpp they import QString
and QDateTime
. I wasn't sure why these aren't included, but my goal was to be as non-destructive as possible while adding what I needed. So I left the base type import in. You can see that this was brought in directly in the old code here on line 5270 in DefaultCodegen.java
@@ -6727,6 +6740,9 @@ private CodegenParameter heeaderToCodegenParameter(Header header, String headerN | |||
CodegenProperty schemaProp = fromProperty(toMediaTypeSchemaName(contentType, mediaTypeSchemaSuffix), mt.getSchema()); | |||
CodegenMediaType codegenMt = new CodegenMediaType(schemaProp, ceMap); | |||
cmtContent.put(contentType, codegenMt); | |||
if (schemaProp != null) { | |||
addImports(imports, schemaProp.getImports(false)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why are we not accepting container type imports here?
objects can be sent in parameters and properties of those objects can $ref to other models
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If I leave this as true, 130 sample files are changed to include List, Set and Map-like imports that were already defined. This is because there seems to be an assumption to include such standard imports in the mustache templates already, and for some reason the duplicates aren't 'known about' in the codegen code. So I opted to optionally refrain from collecting those types. This could be changed later but for now is at least most consisten with what already is happening.
I hope those comments make sense - I was really trying to not change anything about how existing samples would be generated, under the assumption that those work. Instead, I wanted to only effect samples that have the deep recursion. |
Circleci error looks unrelated |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good; thank you for your PR!
recursively search for types during import type collection in deeply nested schemas #11220
Simple change - just recursively adding needed types in the Schema to the imports list.
PR checklist
This is important, as CI jobs will verify all generator outputs of your HEAD commit as it would merge with master.
These must match the expectations made by your contribution.
You may regenerate an individual generator by passing the relevant config(s) as an argument to the script, for example
./bin/generate-samples.sh bin/configs/java*
.For Windows users, please run the script in Git BASH.
master
(5.3.0),6.0.x