Вызывает ли удаление поля из сообщения protobuf проблемы только в случае связи клиент-сервер?
В документах protobuf указано, что:
Удаление полей может вызвать серьезные проблемы, если не будет выполнено должным образом.
Если вам больше не нужно поле и все ссылки удалены из клиентского кода, вы можете удалить определение поля из сообщения. Однако вы должны зарезервировать номер удаленного поля. Если вы не зарезервируете номер поля, разработчик может повторно использовать этот номер в будущем.
Чего я не понимаю, так это того, что я использую кодировку protobuf для связи между моим клиентом и сервером. Таким образом, клиент кодирует данные с помощью protobuf, отправляет запрос по сети, а сервер декодирует тело запроса с помощью protobuf и выполняет некоторую бизнес-логику. И клиент — единственный, кто будет взаимодействовать с этим сервером, поэтому не будет потребителя этого сервера, который, возможно, устарел. Всякий раз, когда сообщения сервера обновляются, клиент, естественно, всегда будет актуальным.
Учитывая все вышесказанное, почему удаление поля или изменение порядка номеров полей сообщений и создание новых прото-сообщений как для клиента, так и для сервера могут вызвать какие-либо проблемы?
Поэтому я предполагаю, что это более важно и актуально, если прото-сообщение хранится на каком-то диске и его необходимо успешно получить, даже если сообщение изменилось. Или сервер имеет своего рода публичный выход в Интернет, и по этой причине API должен быть обратно совместим. Будет ли это правильным предположением @MarcGravell? Независимо от того, так это или нет, вызывают ли зарезервированные поля какие-либо издержки производительности при кодировании/декодировании?
«да» первому, «нет» второму (зарезервированные поля не имеют накладных расходов — они просто делают невозможным случайное добавление нового поля со старым номером, на этапе protoc)
Ответы 1
[...] клиент - единственный, кто будет общаться с этим сервер, поэтому не будет потребителя этого сервера, что, возможно, устаревший. Всякий раз, когда сообщения сервера обновляются, клиент, естественно, быть всегда в курсе событий.
Если вы это предполагаете, вы можете делать все, что захотите, в любой кодировке.
К сожалению, в большинстве случаев это неправильно. Вам просто нужно откатить неисправный клиент или сервер, или у вас небольшая разница во времени обновления клиента и сервера (поскольку сервер все еще завершает работу, а клиент уже новый), и вы находитесь в ситуации, когда версии клиентов и сервера не совпадают.
Одна из прекрасных особенностей протокольных буферов заключается в том, что у вас есть бесплатная обратная и прямая совместимость, если вы просто следуете нескольким простым правилам.
Не будет, если вы сделали это внимательно (и пока оно не отмечено
required), т. е. сначала убедились, что сервер не использует значение, затем прекратили отправку значения, а затем удалили определение в целом;