[Protobuf] Make it possible to override field numbers using x-protobuf-index #7002
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
As described in issue #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 thex-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: ifx-protobuf-index
is not specified, then the current behavior based onx-index
still applies. In other words: this is backward compatible.For example, the following data definition:
... will generate the below protobuf message:
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
./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.master