2

example:

message Foo {
  ...
  string AccountToken = 3
  string BusinessToken = 4
  ...
}

since those 2 fields want to be deprecated by the project owner, can I safely remove those 2 fields just by deleting and regenerate the code then remove all reference?

Kokizzu
  • 24,974
  • 37
  • 137
  • 233
  • 2
    so it won't be backward compatible? why not use obsoleted/deprecated syntax? – Lei Yang Apr 07 '22 at 13:00
  • 1
    altenative to marking deprecated: leave a field reservation (both the name and the old numbers), or at least a comment in the .proto so you know that they used to exist – Marc Gravell Apr 07 '22 at 13:18
  • 1
    could you change the `string` names inside your example, it is ambiguous with the string type and I could modify my answer accordingly ? – Clément Jean Apr 08 '22 at 03:23

2 Answers2

2

Yes you can remove them. If the other side still sends these fields your newer code will just ignore them. But just like @LeiYang mentioned, use the deprecated syntax. Things will go wrong if a developer later uses index 3 or 4 for a different field. Especially if it is not of the same type, string in your case.

Kokizzu
  • 24,974
  • 37
  • 137
  • 233
Bart
  • 1,405
  • 6
  • 32
2

It is important to understand that the serialisation of Protocol Buffers is made possible with these tags. Removing them could cause unexpected behaviours during deserialisation.

So be aware that removing these two fields and not using the reserved keyword can break backward and forward compatibility. If a later version of your schema uses the 3 and 4 as tags and some old version of your code still use these tags as AccountToken and BusinessToken, you'll have unexpected behaviours.

in order to safely remove these fields, you can do:

message Foo {
  reserved 3, 4;
  ...
}

and optionally you can reserve the field name so that the schema do not use the AccountToken and BusinessToken fields' name and thus don't conflict with your code (eg: you go back to older version of your code and a field is called business_token but it doesn't have the same meaning anymore with the new schema). To do that you can do:

message Foo {
  reserved 3, 4;
  reserved "business_token", "account_token"; // assuming they are called like this
  ...
}

By doing the first step, and optionally the second, you ensure full compatibility (backward and forward).

Clément Jean
  • 1,735
  • 1
  • 14
  • 32
  • 1
    This is a good explanation but please note that you will only get unexpected behavior if you reuse the tags. If you never use them again you can just receive data which includes these tags. – Bart Apr 08 '22 at 07:16
  • @Bart I totally agree, I'm just saying that to be safe, you'd better use reserved fields. That prevent 100% of unexpected behavior and it cost you a minute of your time. – Clément Jean Apr 08 '22 at 08:57
  • 1
    Fully agree. Better safe than sorry especially if you work in a team. – Bart Apr 08 '22 at 10:45