Created by: jmini
PR checklist
-
Read the contribution guidelines. -
Ran the shell script under ./bin/
to update Petstore sample so that CIs can verify the change. (For instance, only need to run./bin/{LANG}-petstore.sh
and./bin/security/{LANG}-petstore.sh
if updating the {LANG} (e.g. php, ruby, python, etc) code generator or {LANG} client's mustache templates). Windows batch files can be found in.\bin\windows\
. -
Filed the PR against the correct branch: master
,. Default:3.4.x
,4.0.x
master
. -
Copied the technical committee to review the pull request if your PR is targeting a particular programming language. @OpenAPITools/generator-core-team
Description of the PR
In order to solve #1927 I will need to access the OpenAPI instance in DefaultCodegen#toDefaultValue(..)
in order to be able to see if the schema contains a $ref
and if this is the case, to see if the referenced schema has a default value or not.
The main change of this PR is to have:
public String toDefaultValue(Schema p, OpenAPI openAPI)
Instead ofpublic String toDefaultValue(Schema p)
To fulfill this requirement the OpenAPI
is added as parameter to some methods of DefaultCodegen
.
Some of those methods also had Map<String, Schema> allDefinitions
which corresponds to openAPI.getComponents().getSchemas()
. This parameter was also removed from the methods, and the openAPI
instance is used to access to all schemas.
Based on feedback the initial intention of this PR was changed.
Historically, to access the OpenAPI
instance, or all schemas of the OpenAPI instance, parameters were used in different methods. Example:
CodegenConfig#fromOperation(String, String, Operation, Map<String, Schema>, OpenAPI)
CodegenConfig#fromModel(String, Schema, Map<String, Schema>)
DefaultCodegen#fromResponse(OpenAPI, String, ApiResponse)
DefaultCodegen#DefaultCodegen.fromRequestBody(RequestBody, Map<String, Schema>, Set<String>, String)
DefaultCodegen#createDiscriminator(String, Schema, Map<String, Schema>)
- ...
Then @wing328 noticed that access to this information is requested in a lot of places (for unaliasing).
So he introduced a new approach: having two members globalOpenAPI
and globalSchemas
.
Having two ways for doing the same task is not consistent. It is harder to understand, to maintain and can lead to errors (for example all the unit tests were not using globalOpenAPI
, meaning that they were not reproducing real cases, because when the generator is used for real, then the globalOpenAPI
member is set).
This PR cleans the situation by removing the original approach completely. There is no openAPI
or allDefinitions
parameter anymore in the methods. Instead they use the globalOpenAPI
member which is renamed openAPI
.
In addition globalSchemas
was only a convenient and null-pointer safe access to openAPI.getComponents().getSchemas()
. It is also removed.
This change is mentioned in the migration guide "From 3.x to 4.0.0"
In my opinion the PR improves the readability of the code and reduces the potential coding mistakes.