6

I have a protobuf message like this:

message MyMessage{
    string foo = 1;
    int toBeRemovedBar = 2 [deprecated = true];
    string zag = 3;
}

toBeRemovedBar attribute is no longer required and needs to be removed. As per the guidelines here and here, I could reserve either the field name or the number. What is the best practice here?

  • Reserve either the field number or name
  • Reserve both field number and name

Reserving field number would prevent only the reuse of the field number. Reuse of the field name could not be prevented. Similar argument holds good for reserving only the field name.

So, the right way to remove an attribute is to reserve both field name and number as given below?

message MyMessage{
    string foo = 1;

    reserved 2;
    reserved "toBeRemovedBar";

    string zag = 3;
}
Sarvesh
  • 519
  • 1
  • 8
  • 16
  • 1
    Are you ever using the JSON transport? (gRPC usually uses the binary transport); names are far less interesting if you aren't using JSON anywhere – Marc Gravell Oct 07 '20 at 16:47
  • @marcGravell We are using the default protobuf encoding and there is no plan to use JSON. However, following is the scenario I think of: 1. _tobeRemovedBar_ is not reserved and some field is named the same in next version. 2. There are old consumers that still interpret _toBeRemovedBar_ at field number 2. 3. Will the new 'toBeRemovedBar' (say at field 4) cause problems? The consumer assumes it is the attribute at field number 2 but it is not. – Sarvesh Oct 08 '20 at 09:05
  • Decided to reserve both the field number and name to avoid compatibility issues in future – Sarvesh Oct 12 '20 at 13:44

2 Answers2

6

You should reserve the field number. This will prevent new fields from being added with the same tag, which would result in a wire incompatibility for any users running an old build that has the legacy field compiled in. Reusing the name is fine from a wire-compatibility standpoint, although doing so could cause some confusion.

Doug Fawley
  • 953
  • 5
  • 7
2

It seems good to me.

In this way you prevent both the field number and the name from being used in future. I did the same in a work project because I had to be sure that both the field number and the name wouldn't be used again.

LeonFibuck
  • 336
  • 2
  • 12