Необязательное (повторное) поле в прото 3

Question

Я использую protobuf и синтаксис proto 3 для определения сообщений.

Я хочу иметь возможность проводить различие между полями, когда их значения не были предоставлены (не указаны) и когда их значения были установлены /осталось их значения по умолчанию (0 для int32, [] для повторного и т. д.).Для значений есть хорошо известная оболочка, которая позволяет это делать, но для пользовательских сообщений - свои.

Некоторые люди придумали технику, основанную на одной из них, но она не работает с коллекциями (повторяющимися или отображениями).).

Теперь я начинаю рассматривать просто систематическое написание оболочек для каждого сообщения.

message MyMessage {
  int32 id = 1;
  string name = 2;
  // ...
  message Optional {
    MyMessage value = 1;
  }
  message OptionalRepeated {
    repeated MyMessage values = 1;
  }    
}

Даже если MyMessage.OptionalRepeated или MyMessage.Optional никогда не будет использоваться.

Я полагаю, что люди должны полагаться на такой шаблон, поэтому, возможно, уже есть инструмент, который может автоматически генерировать этот шаблонный код.Знаете ли вы инструмент, чтобы уменьшить это бремя?Или еще лучше, есть ли лучший подход?

Answer 1

Во многих случаях может быть лучше явно передать значение, которое вы пытаетесь неявно передать с помощью необязательных полей.

Часто это может быть просто отдельное поле bool. Рассмотрим для примера:

message UpdateParameters
{
   bool updateServerList = 1;
   repeated ServerType serverList = 2;
}

Это дает понять любому, кто читает код, что если вы хотите обновить до [], вы просто установите updateServerList = true и serverList = []. Если бы это было одно поле типа optionalServerList, не очень ясно, что произойдет, если параметр просто отсутствует, и, с другой стороны, без дополнительных комментариев различие между пустым и отсутствующим может быть потеряно для любого, кто реализует другую сторону протокол.

Наличие отдельного поля также предоставляет больше возможностей для обновлений, сохраняющих совместимость. Например, вы можете добавить Timestamp updateIfOlderThan = 3;, сохраняя при этом возможность отдельно определять поведение для старых клиентов, которые знают только поле true/false.