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

Resolve several issues in generated Go code #8491

Merged
merged 23 commits into from
Jan 21, 2022
Merged

Conversation

aeneasr
Copy link
Contributor

@aeneasr aeneasr commented Jan 20, 2021

This PR resolves several generated Go-client code issues which resolve compilation errors, improve return and field types (pointer vs value) to better match idiomatic Go-style.

Closes #8489
See #8489
See #8485

PR checklist

  • Read the contribution guidelines.
  • Pull Request title clearly describes the work in the pull request and Pull Request description provides details about how to validate the work. Missing information here may result in delayed response from the community.
  • Run the following to build the project and update samples:
    ./mvnw clean package 
    ./bin/generate-samples.sh
    ./bin/utils/export_docs_generators.sh
    
    Commit all changed files.
    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.
  • File the PR against the correct branch: master, 5.1.x, 6.0.x
  • If your PR is targeting a particular programming language, @mention the technical committee members, so they are more likely to review the pull request.

@antihax @grokify @kemokemo @jirikuncar

@aeneasr aeneasr force-pushed the fix-go branch 2 times, most recently from 9369c07 to ec11480 Compare January 23, 2021 11:58
@aeneasr
Copy link
Contributor Author

aeneasr commented Jan 23, 2021

I don't understand why this fails. The go tests run locally fine. Any ideas?

@aeneasr
Copy link
Contributor Author

aeneasr commented Jan 25, 2021

@antihax @grokify @kemokemo @jirikuncar this patch includes some major improvements to the Go generated client code. It resolves several bugs and improves readability of the consumed go code by using best practice, idiomatic, Go patterns. I would appreciate a review and potentially some help around resolving the CI issue as I can not reproduce it locally!

@aeneasr
Copy link
Contributor Author

aeneasr commented Mar 11, 2021

I know that reviewing large PRs is very straining. Unfortunately, the Go generator is simply broken at the moment and this PR addresses so many issues in the generated code. I would be really happy to get some pointers what I need to do next in order to get this PR through.

@pmcgleenon
Copy link
Contributor

I'm also getting 405/404 errors when running the integration tests. When I checked it out, the tests were running against the server "petstore.swagger.io".

Looking at what happens during the CI script, it adds this entry to /etc/hosts
127.0.0.1 petstore.swagger.io

Then it starts a docker container "swaggerapi/petstore" which I guess is the local server that we need, so the tests are communicating with the server inside the docker image

Here's the CI script
https://github.com/cognitedata/openapi-generator/blob/fix/cogniteTypes/circle.yml

@aeneasr is it worth a try with a similar setup to see if something obvious is going causing the test failure?

@wing328
Copy link
Member

wing328 commented Mar 23, 2021

@aeneasr Thanks again for the PR. Let me review shortly. We were busy with the v5.1.0 release.

@wing328 wing328 added this to the 5.1.1 milestone Mar 23, 2021
_ioutil "io/ioutil"
_nethttp "net/http"
_neturl "net/url"
"context"
Copy link
Member

Choose a reason for hiding this comment

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

What if one of the parameter names in the operation is context? Will that result in issues after this change?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

iirc all methods used are upper-case as they would not be exported otherwise, meaning that context can not conflict with one of those. However, I might have missed something - do you have a specific place in mind that could conflict here?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Ok, so I looked into this. The thing is, context is only used in a few places - primarily in structs, variable declarations, and function signatures:

type AdminApiApiCreateIdentityRequest struct {
	ctx            context.Context
	ApiService     *AdminApiService
	createIdentity *CreateIdentity
}
var (
	_ context.Context
)

func (a *AdminApiService) CreateIdentity(ctx context.Context) AdminApiApiCreateIdentityRequest {
	return AdminApiApiCreateIdentityRequest{
		ApiService: a,
		ctx:        ctx,
	}
}

In all of those cases there can never be an overshadowing variable clash. So yes, this is safe!

@@ -447,6 +447,13 @@ func reportError(format string, a ...interface{}) error {
return fmt.Errorf(format, a...)
}

// Prevent trying to import "bytes"
Copy link
Member

Choose a reason for hiding this comment

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

Not sure what you mean by this. Any issues using bytes?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Right, this is a bit confusing. The problem is that in another file bytes might or might not be needed as an import. By defining the function here, as bytes is always required then, we avoid unused import / undefined import. This is the same as fmt.Errorf but the comment can probably be improved:

Suggested change
// Prevent trying to import "bytes"
// A wrapper for strict JSON decoding

@@ -1,14 +1,16 @@
// {{classname}} - {{#description}}{{{description}}}{{/description}}{{^description}}struct for {{{classname}}}{{/description}}
type {{classname}} struct {
{{#oneOf}}
{{{.}}} *{{{.}}}
{{#lambda.titlecase}}{{{.}}}{{/lambda.titlecase}} *{{{.}}}
Copy link
Member

Choose a reason for hiding this comment

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

Do you have a mininal spec to show the issue related to this fix?

We may better fix it in the Go client generator (java class) instead.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes, so the problem is if we have simple types in the oneOf (bool, float, string) as we generate

type UiNodeInputAttributesValue struct {
	bool    *bool
	float32 *float32
	string  *string
}

from

      "uiNodeInputAttributesValue": {
        "oneOf": [
          {
            "type": "string"
          },
          {
            "type": "number"
          },
          {
            "type": "boolean"
          }
        ]
      },

Using the upper case variant here fixes that:

type UiNodeInputAttributesValue struct {
	Bool    *bool
	Float32 *float32
	String  *string
}

@aeneasr aeneasr force-pushed the fix-go branch 2 times, most recently from b30cbed to 29ecad8 Compare March 24, 2021 22:37
@aeneasr
Copy link
Contributor Author

aeneasr commented Mar 25, 2021

Thank you for your help! I've addressed everything, and tests now pass also. From my side this is good to go :)

We will be switching to this generator for all of https://github.com/ory/ / https://www.ory.sh and given that we have large and complex api specs I'll very likely come back with more fixes and improvements :)

@wing328 wing328 added this to the 5.3.1 milestone Oct 25, 2021
@aeneasr
Copy link
Contributor Author

aeneasr commented Nov 1, 2021

Looks like this just won't get addressed @wing328 , so I'll just go ahead and close this!

@aeneasr aeneasr closed this Nov 1, 2021
@tbalthazar
Copy link

This PR is a lot of work and has lots of nice improvements, thanks @aeneasr.
I'm grateful for all the work that has already been put on the project by the maintainers and contributors and I'd love to understand why this hasn't been merged. Has support for the Go generator been discontinued? Or is everybody just super busy? It would help clarify the current status of the Go generator. Cc: @wing328 @jirikuncar

@aeneasr
Copy link
Contributor Author

aeneasr commented Jan 2, 2022

Thank you @tbalthazar ! I have been asked by several people to reopen the PR in hopes it gets merged at some point. So reopening!

@wing328 I know how difficult it is to maintain such a large project. �If there's anything I can do to help and get things resolved please let me know. I'll do my best :)

@aeneasr aeneasr reopened this Jan 2, 2022
@wing328
Copy link
Member

wing328 commented Jan 2, 2022

@aeneasr first of all thanks again for the PR. I left some feedback before but didn't have time to review your replies.

Can you please merge the latest master into your branch and I'll try to take another look this week? Thanks again for your work.

@aeneasr
Copy link
Contributor Author

aeneasr commented Jan 2, 2022

No problem, I'll get on it immediately!

# Conflicts:
#	modules/openapi-generator/src/main/resources/go/api.mustache
#	modules/openapi-generator/src/main/resources/go/model_simple.mustache
#	samples/client/petstore/go/go-petstore/api_another_fake.go
#	samples/client/petstore/go/go-petstore/api_fake.go
#	samples/client/petstore/go/go-petstore/api_fake_classname_tags123.go
#	samples/client/petstore/go/go-petstore/api_pet.go
#	samples/client/petstore/go/go-petstore/api_store.go
#	samples/client/petstore/go/go-petstore/api_user.go
#	samples/openapi3/client/extensions/x-auth-id-alias/go-experimental/api_usage.go
#	samples/openapi3/client/petstore/go/go-petstore/api_another_fake.go
#	samples/openapi3/client/petstore/go/go-petstore/api_default.go
#	samples/openapi3/client/petstore/go/go-petstore/api_fake.go
#	samples/openapi3/client/petstore/go/go-petstore/api_fake_classname_tags123.go
#	samples/openapi3/client/petstore/go/go-petstore/api_pet.go
#	samples/openapi3/client/petstore/go/go-petstore/api_store.go
#	samples/openapi3/client/petstore/go/go-petstore/api_user.go
#	samples/openapi3/client/petstore/go/go-petstore/model_nullable_class.go
@aeneasr
Copy link
Contributor Author

aeneasr commented Jan 3, 2022

@wing328 issues resolved, CI passes! It's good to go! :)

Copy link
Contributor

@jirikuncar jirikuncar left a comment

Choose a reason for hiding this comment

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

nit: can you please replace spaces with a tab?

aeneasr and others added 2 commits January 3, 2022 13:32
@aeneasr
Copy link
Contributor Author

aeneasr commented Jan 3, 2022

Done :)

@aeneasr
Copy link
Contributor Author

aeneasr commented Jan 3, 2022

CI passed again, everything green, good to go! :)

@wing328
Copy link
Member

wing328 commented Jan 11, 2022

@jirikuncar thanks for reviewing the change.

@aeneasr thanks again for your work. Can you please PM me via Slack for a few quick questions when you've time? https://join.slack.com/t/openapi-generator/shared_invite/enQtNzAyNDMyOTU0OTE1LTY5ZDBiNDI5NzI5ZjQ1Y2E5OWVjMjZkYzY1ZGM2MWQ4YWFjMzcyNDY5MGI4NjQxNDBiMTlmZTc5NjY2ZTQ5MGM

My timezone is +0800 (Hong Kong).

@wing328
Copy link
Member

wing328 commented Jan 21, 2022

Tested locally and the result is good. Thanks for the PR and sorry again for the delay in reviewing the change

@wing328 wing328 merged commit 93488f4 into OpenAPITools:master Jan 21, 2022
@aeneasr
Copy link
Contributor Author

aeneasr commented Jan 21, 2022

@wing328 thank you so much for reviewing and merging this and reaching out on Slack!!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[BUG] [Go] oneOf generates uncompilable code for primitive types
6 participants