Skip to content
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

Kotlin spring server codegen improvements #1070

Merged
merged 5 commits into from
Sep 21, 2018

Conversation

herojan
Copy link
Contributor

@herojan herojan commented Sep 20, 2018

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, 3.3.x, 4.0.x. Default: master.
  • Copied the technical committee to review the pull request if your PR is targeting a particular programming language.
    @dr4ke616

Description of the PR

  • Fixes a bug where lists were instantiated with the arrayOf function.
  • If required and readonly, a field should be optional. This is to allow people to do a GET and easily PUT it back with small changes.
  • Use List type for the OpenApi array. This is because kotlin data classes should not use kotlin.Array since arrays are compared by reference rather than structure. Different arrays with the same content should return true but return false.
  • Uses String instead of kotlin.String, Int instead of kotlin.Int, etc for built-in kotlin types.

@wing328
Copy link
Member

wing328 commented Sep 20, 2018

Thanks for the PR but your commit (as shown in the Commits tab) is not linked to your Github account, which means this PR won't count as your contribution in https://github.com/OpenAPITools/openapi-generator/graphs/contributors.

Let me know if you need help fixing it.

Ref: https://github.com/OpenAPITools/openapi-generator/wiki/FAQ#how-can-i-update-commits-that-are-not-linked-to-my-github-account

@@ -173,7 +173,7 @@ public AbstractKotlinCodegen() {
typeMapping.put("DateTime", "java.time.LocalDateTime");

instantiationTypes.put("array", "kotlin.arrayOf");
instantiationTypes.put("list", "kotlin.arrayOf");
instantiationTypes.put("list", "kotlin.listOf");
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This will also impact other Kotline generators (e.g. client).

@jimschubert @dr4ke616, are you ok with that?

Copy link
Contributor

@dr4ke616 dr4ke616 Sep 21, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think for the spring boot code gen it should be fine, it does seem like an obvious mistake.

There are no diffs in other kotlin code generators when re-building the samples, so I'm guessing its ok. @jimschubert any thoughts?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Array was being used over List because of the serializer. That's since been changed, so this shouldn't be an issue as far as language support is concerned. We could always just generate the client to hit a service created by the Springboot generator to verify.

However, this will break client consumers who have coded to array.

Another thing to consider is that Kotlin arrays are compiled to Java arrays. These are more lightweight than List. So this change may also have an impact on resource limited consumers (Android).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jimschubert Ah ok, I'll change it back in that case. Out of interest though is list being used as a type in OpenApi specs? I thought this map was from openapi types but I don't see list anywhere

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@herojan these types represent openapi data types as well as other common types that have been normalized in DefaultCodegen. I'm on mobile, so it's hard to search GitHub, but if I remember correctly the DefaultCodegen logic (originally targeting mainly Java) treated OpenAPI array types as array of they were primitives or list if not. It's been about a year since I looked through that code, so that's pretty off memory. But, for example, you could have a type File and instantiate it with some custom infrastructure type like MyFileMaker.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jimschubert Ah right that makes sense, good to know. Thanks!

@herojan herojan force-pushed the required-readonly-optional branch 4 times, most recently from efc5500 to de4ffd6 Compare September 21, 2018 08:44

@get:NotNull
@get:NotNull
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Formatting here looks a little inconsistent

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed that now

@dr4ke616 dr4ke616 merged commit abb2690 into OpenAPITools:master Sep 21, 2018
@wing328 wing328 added this to the 3.3.0 milestone Oct 1, 2018
A-Joshi pushed a commit to ihsmarkitoss/openapi-generator that referenced this pull request Feb 27, 2019
* If required and readonly, a field should be optional. This is to allow people to get and easily put back.

* Use list instead of array, use String instead of kotlin.String etc

* Update samples

* code review: fix annotation formatting

* code review: revert change to use listOf
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants