Я читаю этот пост на protobuf, поскольку использую grpc json для замены существующих клиентов на использование нашего json на grpc ... https://github.com/protocolbuffers/protobuf/issues/1451
builder.setName (null) не поддерживается, поскольку формат провода «не» отправляет значение null. Если это так, как мне сделать json-эквивалент этих случаев
- "name": 1234
- "name": 0 // {defaultValue = 0 для int} на проводе
- "имя": ноль
- {имя не существует}
для меня «not» вызов setName в protobuf будет == {name not exist} в двоичном формате, а вместо этого будет name = 0 в двоичном формате. Как указать в protobuf этот случай, чтобы я мог оставаться совместимым с нашими существующими клиентами в json при переходе на protobuf?
В частности, ДЛЯ Java нам нужен метод setAge (), и если я НЕ назову его, поле не будет существовать. Если я вызываю setAge (null), он упорядочивает «age»: null. Если я вызову setAge (0), он упорядочит «age»: 0 (значение по умолчанию). Если я вызываю setAge (56) значение, отличное от значения по умолчанию, оно маршалирует «возраст»: 56
Затем нам нужно то же самое с protobuf. Конечно, формат провода МОЖЕТ добавить дополнительные поля. Это нормально, и это связано с тем, что значения по умолчанию не упорядочиваются по сети, поэтому невозможно отличить нулевое значение от значения по умолчанию :(. Мы согласны с дополнительными данными по сети для KISS для разработчиков.
Есть ли прототипная схема, которую мы можем использовать для этого, чтобы иметь простые методы setAge (null), которые переходят в "name": null.
Вот что я пытаюсь сделать прямо сейчас для вышеуказанного
message SomeMessage {
string clientId = 1;
oneof optional_result { // "optional_" prefix here just serves as an indicator, not keyword in proto2
bool isAccepted = 5;
}
}
Затем я вижу метод getIsAccepted (), который возвращает логическое значение. Я не вижу поля для hasIsAccepted (). Я не уверен, как определить схему для сопоставления с этим «одним-единственным» json-полем.
LOL, потому что я только что добавил grpc json на нашу платформу и не уверен, может ли protobuf поддерживать все варианты использования json ....
https://github.com/deanhiller/webpieces/tree/master/webserver-plugins/plugin-grpc-json
Бизнес-кейс: некоторые клиенты спрашивают, что нам нужно true, если страховка принята, и false, если не принята, и null, если ее не существует. Здесь у нас есть тройные варианты использования.
спасибо, Дин
