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

Revert "[+] support integer64 as string option (#355)" #431

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

ajorgensen
Copy link

@ajorgensen ajorgensen commented Mar 7, 2024

ref: #355
closes: #411

This reverts commit c62333b.

The original change conflated generating an OpenAPI v3 spec file with the guidance for encoding protobuf messages as json objects. OpenAPI v3 explicitly allows for integer types of int64 (https://swagger.io/docs/specification/data-models/data-types/#numbers). The OpenAPI v3 spec generated by this tool will then usually be fed into language specific generators which will determine how they want to handle each of the types depending on the specific target language.

@ajorgensen ajorgensen requested a review from a team as a code owner March 7, 2024 17:23
Copy link

google-cla bot commented Mar 7, 2024

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

This reverts commit c62333b.

The original change conflated the guidance for encoding protobuf
messages as json objects with generating an OpenAPI v3 spec file.
OpenAPI v3 explicitly allows for integer types of int64
(https://swagger.io/docs/specification/data-models/data-types/#numbers).
The OpenAPI v3 spec generated by this tool will then usually be fed into
language specific generators which will determine how they want to
handle each of the types depending on the specific target language.
@n0v1
Copy link

n0v1 commented Mar 19, 2024

I also think that the generated OpenAPI specification should match the types in the proto file as close as possible and should not be language-specific. So for proto type int64 I would expect {"type": "integer", "format": "int64"} as it was before instead of {"type": "string"}.

@suncle1993
Copy link

Is there any update in this bug?

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

Successfully merging this pull request may close these issues.

protoc-gen-openapi BUG
4 participants