RFC: [go] define "any-type" schema as an empty interface in generated go code.#888
RFC: [go] define "any-type" schema as an empty interface in generated go code.#888ashanbrown wants to merge 2 commits intoOpenAPITools:masterfrom launchdarkly:ashanbrown/any-type
Conversation
|
@ashanbrown thanks for the PR. cc the technical committee for review: |
|
I was also thinking that maybe we should push the problem upward any introduce an "anytype" |
| type = openAPIType; | ||
| } else { | ||
| // Handle "any type" as an empty interface | ||
| if (openAPIType == "object" && p != null && !ModelUtils.isObjectSchema(p) && !ModelUtils.isMapSchema(p)) { |
There was a problem hiding this comment.
@ashanbrown Please use "object".equals(openAPIType) instead
There was a problem hiding this comment.
@ashanbrown can you please fix it? Here in Arduino we really appreciate to have this PR merged :)
There was a problem hiding this comment.
Sure @eclipse1985, I've made that change. It wasn't sure that the team was really offering to merge this though because I didn't see further comments from @antihax, @bvwells or @grokify about this or my follow-up comment at #888 (comment). I'd still be happy to have this merged as is but my impression was there might be a larger issue here.
|
Looking through the code I noticed that a number of other (not go) generators have a concept of an "any" type. I'm wondering if if we should just always return "any" for all code generators and let the individual generators map the type to the a primitive, as shown in: |
|
Hey there! Any update on this? We really need it :) |
bkabrda
left a comment
There was a problem hiding this comment.
Strictly speaking, according to openapi-spec, the current implementation is correct. openapi-spec takes type definitions from JSON schema (with some further restrictions, which don't apply to this case). JSON schema specifies that object is "unordered set of properties mapping a string to an instance" [1].
On the other hand, I see the usecase that is broken right now and would be fixed by merging this PR, so with my go-language-committee member hat on, I'm ok with this PR .
Having said that, we'd probably need to wait for a major release to merge this, because this change would break backwards compatibility after regenerating code. We should rather put this in go-experimental only. @wing328 do you agree with the above? Thanks!
[1] https://tools.ietf.org/html/draft-handrews-json-schema-02#section-4.2.1
| type = openAPIType; | ||
| } else { | ||
| // Handle "any type" as an empty interface | ||
| if (openAPIType.equals("object") && p != null && !ModelUtils.isObjectSchema(p) && !ModelUtils.isMapSchema(p)) { |
There was a problem hiding this comment.
Hmm, it seems this would only work with the following suggestion.
| if (openAPIType.equals("object") && p != null && !ModelUtils.isObjectSchema(p) && !ModelUtils.isMapSchema(p)) { | |
| if (openAPIType.equals("object") && p != null && ModelUtils.isObjectSchema(p) && !ModelUtils.isMapSchema(p)) { |
Indeed, a schema like the following will be an ObjectSchema:
AnyType:
type: objectOtherwise, I agree this should probably be added as part of go-experimental and released in a major
|
@zippolyte @bkabrda I don't have much to add on this as I haven't been working with openapi a lot lately. I don't know if you also looked at the alternate proposal at #3878 by @mattiabertorello. I suspect he has a deeper (and more up-to-date) understanding of how this code works than I do. Any change that allows specification of an arbitrary type is would be fine by me. I don't completely follow the change suggested by @zippolyte and would be reluctant to implement it myself without a corresponding test for the behavior we are expecting. |
|
This is already done: https://github.com/OpenAPITools/openapi-generator/blob/master/modules/openapi-generator/src/main/java/org/openapitools/codegen/languages/AbstractGoCodegen.java#L133 Please give the latest master a try. Closing this PR for the time being. |
I could use some advice on this one. The fix for #51 (PR #60) broke our use of the go generator because it now assumes unspecified (i.e. "any-type") schemas will be
map[string]interface{}instead of*interface{}. This change tries to restore the empty interface, albeit asinterface{}instead of*interface{}. I'm not sure what the intent of using a pointer to an interface was in the original code but maybe that would be preferred . This code does not change the generated petshop code (but maybe petshop should be updated to include an "any-type" schema).The "any-type" schema is mentioned at https://swagger.io/docs/specification/data-models/data-types/ which claims to be a guide to openapi 3.0, but I don't see it mentioned by name in the "open-api" spec.
Thanks for your help and for keeping this project moving forward.
PR checklist
./bin/to update Petstore sample so that CIs can verify the change. (For instance, only need to run./bin/{LANG}-petstore.shand./bin/security/{LANG}-petstore.shif 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\.master,3.3.x,4.0.x. Default:master.Description of the PR
(details of the change, additional tests that have been done, reference to the issue for tracking, etc)