0

Lets say I have a message

message Something {
  int32 foo = 1;
  int32 bar = 2;
  string baz = 3;
}

and I want to change baz to be repeated string. Do I actually have to change the number? (For example to 4 and deprecate 3).

A friend and I are debating this. He's more experienced at protobuffs (which I am a novice at) but from my reading of the docs I actually don't see why it would be necessary.

While the docs don't address the issue directly that I've seen, my reasoning is as follows:

The above might serialize to something like

0001(32bits)0011(utf-8bits)0010(32bits)

And deserialization would basically read it as

  • oh ok, that's a 1, so read the next 32 bits
  • oh ok, that's a 3, so read the next bits as a utf-8
  • hmm, next one is a 2, so read the next 32 as that

So according to the doc when you add repeated:

this field can be repeated any number of times (including zero) in a well-formed message

Which tells me that the actual number of bits we read when encountering a 3 is not going to be any different, we just might encounter multiple threes. It is therefore validation when serializing and deserializing but not actually part of the encoding.

Is that logic correct? Can I keep using the same number? Or am I missing something?

George Mauer
  • 117,483
  • 131
  • 382
  • 612

1 Answers1

1

From the language guide:

optional is compatible with repeated. Given serialized data of a repeated field as input, clients that expect this field to be optional will take the last input value if it's a primitive type field or merge all input elements if it's a message type field.

(proto2: https://developers.google.com/protocol-buffers/docs/proto#updating )

This is valid for proto2, I would say that this still apply to proto3 even if not specified. The behavior should be that the legacy code will process the list and keep in memory the last value read.

When changing a field from optional to repeated, I would pay as well attention to the API change. This is maybe what your friend is trying to highlight.

Luc
  • 1,393
  • 1
  • 6
  • 14