-
-
Notifications
You must be signed in to change notification settings - Fork 6.4k
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
[DefaultCodegen] Possible missing model for request body for OAS 3.0 #8
Comments
I think that all generators are concerned by the issue. This should be improved at DefaultCodegen level. The inline form is broken as well (tested with a java generator)
— I have investigated a little bit, comparing these 2 cases (can be added to
In the second case in the case where the Our test suite is working because of the The current workaround is to write your spec like this:
|
Consider case reported by @macjohnny in #222 when solving this issue. |
Consider case reported in #304, i.e. with OAS 2.0 |
I've just independently re-discovered this in #659 (#99 and #231 look like more of the same). This is a rather unfortunate regression from swagger-codegen. It is easy enough to work around, but a bit of a pain when trying to persuade other people to switch to openapi-generator. From looking through the code, it seems as if the loss of |
@bjgill thank you for the analysis, do you think you can propose a PR for this? |
I've started having a look at restoring InlineModelResolver.java - see https://github.com/bjgill/openapi-generator/tree/InlineModelResolver. I'm now out of time to work on this for now, however. Anyone else who wants to pick this up would be more than welcome. |
I've also started digging through this and trying to resolve the changed function names. Are you actively working on this also? @bjgill |
No - I started work in https://github.com/bjgill/openapi-generator/tree/InlineModelResolver, but am not going to have time to work on this for the foreseeable future. I'd be very happy to let you handle this. |
OK - the following (v2) definition was fixed by #736 (thanks @antihax!): ObjectOfObjects:
description: An object of objects
type: object
properties:
foo:
type: object
properties:
bar:
type: string However, the following still doesn't seem to work (at least for ArrayOfObjects:
description: An array of objects
type: array
items:
properties:
filename:
description: A non-required property
type: string
contents:
description: A required property
type: string
required:
- contents
type: object |
I think support for items in array is exactly targeted by this test: Lines 279 to 303 in e7340bf
(and the next ones) |
I'm pretty sure the Go generator has the same problem (#1112). Is there something I can do to to help that generator? It sounds like a DefaultCodegen fix? I've got an OpenAPI v3 spec, not v2 like mentioned in #8 (comment) |
I figured out my problem. It was missing https://github.com/moov-io/api/pull/43 was the fix for my project |
I just hit by this. still happened on 4.0.0.beta. |
No need for unused StringDescriptor
I am trying to use open api generator 5 to generate a client based on the jira cloud specification. Unfortunately, the request body model for |
merge master
I think this issue have been solved (based on specified schema). |
Propagates generator exit code to the parent NodeJS process
Description
Consider the following spec:
For this spec
CodegenOperation::bodyParam.dataType
equals to "object" and no codegen model is generated for request body. A bit lost why this is happenning because 3 other possible scenarios (inline body + inline schema, inline body + ref schema, ref body + ref schema) work perfectly well.The text was updated successfully, but these errors were encountered: