Protobuf: сохранять смысл номеров полей при изменении пакета

Запросить

Компактный полевой пакет может годами храниться в архиве после обновления прошивки. Если освободившийся номер поля Protobuf использовать для другого значения, старые байты способны получить новый ошибочный смысл. Поэтому изменения схемы оценивают по истории формата и совместимости, а не только по отсутствию ошибки компиляции.

Сохранить исходное определение

Руководство Protocol Buffers proto3 связывает номер поля с бинарным форматом и рекомендует резервировать удалённые номера. (Protocol Buffers — Language Guide proto3) Храните версии исходного proto файла вместе с описанием назначения полей. Удалённая строка из текущего файла не должна уничтожать сведения о ранее занятом номере.

Отдельно укажите, используется ли бинарный формат, ProtoJSON или текстовое представление. Условия совместимости у них различаются. Нельзя переносить вывод о безопасном бинарном изменении на все способы обмена и экспорта, особенно если часть потребителей работает через другой сериализатор.

Описать изменение без переиспользования

Для каждого поля сохраните номер, тип, единицу и смысл отсутствия. Если значение больше не требуется, выполните предусмотренное резервирование. Новая физическая величина должна получить собственное документированное место, а не наследовать номер удалённого измерения ради красивой последовательности.

Условное прежнее поле N после удаления становится reserved, а новая величина не наследует его номер. Три группы приёмки проверяют старые пакеты новым читателем, новые пакеты старым потребителем и граничные случаи. Бинарное, JSON и текстовое представления рассматриваются отдельно.
Буква N заменяет номер учебного поля. Схема сохраняет контракт истории и различает представления; конкретное поведение неизвестных полей и перечислений подтверждают установленными библиотеками и приложением.
Увеличить схему
Условное прежнее поле N после удаления становится reserved, а новая величина не наследует его номер. Три группы приёмки проверяют старые пакеты новым читателем, новые пакеты старым потребителем и граничные случаи. Бинарное, JSON и текстовое представления рассматриваются отдельно.

Переименование также проверяйте в контексте всех форматов. Хотя бинарные данные ориентируются на номера, имена могут использоваться другими представлениями и программами. Не объявляйте изменение полностью безопасным по результату одного бинарного теста, если рабочая интеграция включает текстовые выгрузки.

Проверить собственную библиотеку пакетов

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

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

Защитить историю и откат

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

Приёмка включает старые пакеты, новые пакеты и смешанный маршрут. После этого хозяйство может менять формат осознанно, не превращая прежние измерения в другие величины. Зарезервированные номера становятся частью сохранённого контракта, а успешная компиляция остаётся лишь одним из технических этапов проверки совместимости.

Все разборы