I have a message of the following type

message Foo {
    string bar = 1;
    float baz = 2;
}

Is there any problem in converting it to the following for use in Go ?

message Foo {
    string bar = 1;
    optional float baz = 2;
}

Is the preferred way to deprecate and create a new field in the proto in this case as well ?

CodePudding user response：

The optional will make the field a pointer type. So in Go generated code, optional float will become *float32, which of course is not float32.

To deprecate a field, use [deprecated = true] field option:

message Foo {
    string bar = 1;
    float baz = 2 [deprecated = true];
}

If in subsequent releases of your protobuf schema you actually remove the field altogether from the message, you might want to add reserved 2, where 2 is the number of the field you removed.

message Foo {
    string bar = 1;
    reserved 2;
}

This helps preventing other people or future you from adding a new field in position 2. This is relevant in case you have outdated clients which still expect a float in position 2.

PS: optional fieds in Proto3 are supported from version 3.15

CodePudding user response：

depends on how deeply integrated that particular message is in your code base - meaning

1. are you storing the marshaled binary representation somewhere like your database
2. are different parts of your code base using different versions of the message you are modifying - e.g. older versions of your android/ios apps and such

point being if you use a message structure to unmarshal encoded data, that was not generated with the very same message structure, into - bad things will happen.

The docs recommend adding a new element to circumvent such scenarios entirely. If that is not something you want to do, take the above points into consideration.