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

[go] map type object *interface{} convert problem #51

Closed
ilk opened this issue May 15, 2018 · 9 comments · Fixed by #60
Closed

[go] map type object *interface{} convert problem #51

ilk opened this issue May 15, 2018 · 9 comments · Fixed by #60

Comments

@ilk
Copy link
Contributor

ilk commented May 15, 2018

Description

Definition property "type": "object" gets converted to *interface{} which returns an error when set to a struct or pointer pointer.

openapi-generator version

3.0.0

OpenAPI declaration file content or url
Command line used for generation
Steps to reproduce
Related issues/PRs
Suggest a fix/enhancement

Instead of an *interface{} map the object to map[string]interface{}

@wing328
Copy link
Member

wing328 commented May 15, 2018

@ilk thanks for creating the issue. May I know if you can also share a spec to more easily reproduce the issue?

When using type: object, are you referring to an arbitrary JSON payload?

@ilk
Copy link
Contributor Author

ilk commented May 15, 2018

For example:

...
"Provider" : {
  "type" : "object",
  "properties" : {
    "Foobar" : {
      "type" : "object",
      "description" : "Foobar-specific configuration object"
    },
...

Results to:

type Provider struct {
  Foobar *interface{}
  ...
}

Better would be:

type Provider struct {
  Foobar map[string]interface{}
  ...
}

@louis77
Copy link

louis77 commented May 15, 2018

@ilk @wing328 I agree with ilk's assessment and would appreciate this change too. It'll make the go client more Go-like:

  1. JSON Object type maps properly to Go's map[string]interface{}. This way there is no need to type cast.
  2. Since map/slice/channel values are already pointer wrapper struct values, there is no need in this case to add an additional pointer to them. Handling an *interface{} variable is extremely complex, non Go idiomatic and involves usage of the reflect package - which is not easy to grasp.

@wing328
Copy link
Member

wing328 commented May 15, 2018

@louis77 thanks for the feedback.

cc @antihax @bvwells

@antihax
Copy link
Contributor

antihax commented May 15, 2018 via email

@louis77
Copy link

louis77 commented May 15, 2018

@antihax Which works properly if definitions are used in the OpenAPI Spec.

However, arbitrary inline objects are currently represented as *interface{}'s. To use @ilk 's example, Foobar is an arbitrary inline object, most likely there will be no corresponding struct definition in the Go code that will use the go-client.

@antihax
Copy link
Contributor

antihax commented May 15, 2018

This looks OK in this instance. However it would end up as map[string]string as we cannot determine types on an arbitrary structure?

@louis77
Copy link

louis77 commented May 15, 2018

The AbstractGoCodegen.java implementations plainly maps these objects always to an interface{}:
typeMapping.put("object", "interface{}");

This is now changed to:
typeMapping.put("object", "map[string]interface{}");

So it'll always end up as a map[string]interface{}, there is no further logic involved. In a next release we could think about generating an InlineObject Go type to further abstract the user from low-level accessing of the values inside the map.

@wing328
Copy link
Member

wing328 commented May 16, 2018

Is it correct to say that the proposed change will also work with XML payload (since Go client supports the "withXML" option) ?

	withXml
	    whether to include support for application/xml content type and include XML annotations in the model (works with libraries that provide support for JSON and XML) (Default: false)

@wing328 wing328 modified the milestones: 3.0.0, 3.0.1 Jun 1, 2018
@wing328 wing328 modified the milestones: 3.0.1, 3.0.2 Jun 11, 2018
@jmini jmini modified the milestones: 3.0.2, 3.0.3 Jun 18, 2018
wing328 pushed a commit that referenced this issue Jun 21, 2018
aserkes pushed a commit to aserkes/openapi-generator that referenced this issue Sep 8, 2022
nilskuhn pushed a commit to nilskuhn/openapi-generator that referenced this issue Apr 6, 2023
…r-2.x

chore(deps): update dependency prettier to v2.1.2
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants