CODEWITHSUNDEEP
protocol-buffersgrpc
Christopher Pisz
Christopher Pisz

Reputation: 4010

grpc and protobuf - How to handle a new field when the other side is not releasing in sync

I've got a situation where the other end of the grpc communication is not in sync with their releases. My higher ups, would like me to therefore add a field that is going to work if the other side does or doesn't fill it out, for a short time period (like two weeks)

I believe I can do this by adding it to the end of the proto message such that the indices for the other fields do not change. From, what I've Googled, the optional field is not avail prior to version 3.15, so I have to use a work around.

The workaround that was described to me was to use oneof. However, I am not 100% sure what that looks like. All examples show the oneof field by itself. Are the indices that belong to the oneof values indendent of the indices that belong to the rest of the message?

message TestMessage {  
    string somefield = 1;
    int someotherfield = 2;
    oneof mynewoptionalfield
    {
        string mynewfield = ???? Does this have to be 3 or is it 1?
        int ifihadanother = ???? Does this need to be 4 or 2?
    } 
}

Questions:

Upvotes: 5

Views: 4243

Answers (1)

Eric Anderson
Eric Anderson

Reputation: 26434

Your use-case is exactly what protobufs were designed to handle. All you need to do is: add a new field to the message. In the easiest case, the client application code simply doesn't look at the new field until the server roll-out is complete and so doesn't notice sometimes it is present and other times missing.

You are correct that you should not change the indices (field ids) of the pre-existing fields. Although I'll note that you can add your new field anywhere within the message; the order the fields are written in does not matter for protobuf.

So you'd just add another field like:

message TestMessage {  
    string somefield = 1;
    int someotherfield = 2;
    string mynewfield = 3;
}

You don't have to use 3 as the id. You could use 4, or 10, or 10000. But small numbers are more efficient for protobuf and it is typical to just choose the "next" id. On-the-wire protobuf uses the id to identify the field, so it is important you don't change the id later.

In protobuf 3, all fields are "optional" in the protobuf 2 sense; there are no "required" fields. However, protobuf 2 also provided "field presence" for all fields. Protobuf 3 only provided field presence for oneofs and messages... until the recent re-introduction of the "optional" keyword.

In protobuf 3 if you call textMessage.getMynewfield() it will always return a non-null string. If the string was not sent, it will use the empty string (""). For integers 0 is returned and for messages the "default message" (all defaults) is returned. This is plenty for many use-cases, and may be enough for you.

But let's say you need to distinguish between "" and <notsent>. That's what field presence provides. Messages in protobuf 3 have "has" methods that return true if a value is present. But primitives don't have that presence information. One option is to "box" the primitive with standard wrappers that make the primitive a message. Another option available in newer versions of protobuf is the optional keyword. Both options will provide a method like textMessage.hasMynewfield().

message TestMessage {  
    string somefield = 1;
    int someotherfield = 2;
    google.protobuf.StringValue mynewfield = 3;
    // -or-
    optional string mynewfield = 3;
}

Upvotes: 8

Related Questions