Created by: k0ral
As described in issue https://github.com/OpenAPITools/openapi-generator/issues/6756 . Cc: @dobl1 .
The protobuf generator currently does not guarantee that generated field numbers are preserved across multiple generations: it always generates them as a sequence from 0 to n
(through the x-index
vendor extension). If fields are re-ordered, added, or deleted, field numbers will almost always shift. This is a big deal, as field numbers are part of the binary interface of protobuf serialization format.
This change is making it possible to specify protobuf field numbers using the vendor extension x-protobuf-index
. This is an opt-in feature at field level: if x-protobuf-index
is not specified, then the current behavior based on x-index
still applies. In other words: this is backward compatible.
For example, the following data definition:
Pet:
type: object
properties:
id:
type: integer
x-protobuf-index: 3
name:
type: string
x-protobuf-index: 1
... will generate the below protobuf message:
message Pet {
int64 id = 3;
string name = 1;
}
I do not expect this pull-request to be merged as-is, I rather see it as a conversation-starter: do you agree with the general approach ? How would you suggest I improve the implementation ? I'd rather get feedback before investing time in writing automated tests, for example. For now, I've just manually validated the behavior on a toy example.
PR checklist
-
Read the contribution guidelines. -
If contributing template-only or documentation-only changes which will change sample output, build the project beforehand. -
Run the shell script ./bin/generate-samples.sh
to update all Petstore samples related to your fix. This is important, as CI jobs will verify all generator outputs of your HEAD commit as it would merge with master. These must match the expectations made by your contribution. You may regenerate an individual generator by passing the relevant config(s) as an argument to the script, for example./bin/generate-samples.sh bin/configs/java*
. For Windows users, please run the script in Git BASH. -
File the PR against the correct branch: master
-
Copy the technical committee to review the pull request if your PR is targeting a particular programming language.