[go] map type object *interface{} convert problem about openapi-generator HOT 9 CLOSED

@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?

from openapi-generator.

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{}
  ...
}

from openapi-generator.

@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.

from openapi-generator.

@louis77 thanks for the feedback.

cc @antihax @bvwells

from openapi-generator.

from openapi-generator.

@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.

from openapi-generator.

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

from openapi-generator.

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.

from openapi-generator.

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)

from openapi-generator.