Does removing existing field from protobuf message cause issues?
S

2

16

I am having one protobuf message -

message Sample{
    string field1 = 1;
    string field2 = 2;
    string field3 = 3;
}

These messages are stored in datastore in binary format. So if I want to remove any of the defined field in the above message will it cause any issue in deserialization of the message from datastore?

Smothers answered 8/7, 2020 at 12:35 Comment(0)
B
24

No. Removing fields is fine, although you might want to mark it reserved so that nobody reuses it in an incompatible way. New code with old data (with the field) will silently ignore it; old code with new data will just load without the field populated, since everything in proto3 is implicitly optional. This was more of a problem in proto2, when required was a thing. Another option is to leave the field but mark it with [deprecated = true] - it'll still exist and be populated, but some tools will mark the member with the platform-specific obsolete markers for that language/framework.

Breen answered 8/7, 2020 at 13:39 Comment(5)
Thanks for help. This documentation says the same - developers.google.com/protocol-buffers/docs/proto3#updatingSmothers
@RahulVedpathak Please accept the answer if it solved your problem.Bond
Could you remove the field, and then reuse the field number at a later time, if you could guarantee that there is no code anywhere that is still assuming the field number refers to the old field?Tyrontyrone
@JamesWierzba you'd also need to guarantee that no persisted data (files, cache, databases, etc) uses the old data. Honestly, it just isn't worth the risk. Use a new number.Breen
added a link to reserved fields doc developers.google.com/protocol-buffers/docs/proto3#reservedToplofty
K
3

Adding and removing fields will not cause safety issues as mentioned in the answer from Marc. The only safety you should care about it is to mark the field as reserved. This will ensure that no one uses the same field number accidentally in future

Kellerman answered 9/1, 2022 at 20:4 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.