为什么在协议缓冲区3中删除了必需和可选的内容 [英] Why required and optional is removed in Protocol Buffers 3

问题描述

我最近将gRPC与proto3一起使用，并且我注意到required和optional已被新语法删除.

I'm recently using gRPC with proto3, and I've noticed that required and optional has been removed in new syntax.

有人能解释一下为什么在proto3中删除了必需的/可选的吗?这种约束似乎对于使定义更健壮很有必要.

Would anyone kindly explain why required/optional are removed in proto3? Such kind of constraints just seem necessary to make definition robust.

语法proto2:

message SearchRequest {
  required string query = 1;
  optional int32 page_number = 2;
  optional int32 result_per_page = 3;
}

语法proto3:

syntax = "proto3";
message SearchRequest {
  string query = 1;
  int32 page_number = 2;
  int32 result_per_page = 3;
}

推荐答案

required的用途一直是许多辩论和火焰战争的核心.双方都有大营地.一个营地喜欢保证存在一个价值，并愿意忍受它的局限性，但是另一个营地感到required危险或无益，因为它不能安全地添加或删除.

The usefulness of required has been at the heart of many a debate and flame war. Large camps have existed on both sides. One camp liked guaranteeing a value was present and was willing to live with its limitations but the other camp felt required dangerous or unhelpful as it can't be safely added nor removed.

让我解释一下为什么应该少用required字段的更多原因.如果您已经在使用原型，则无法添加必填字段，因为旧的应用程序不会提供该字段，并且应用程序通常无法很好地处理故障.您可以确保首先升级所有旧的应用程序，但是容易出错，如果将原型存储在 any 数据存储区中(即使是短暂的，例如memcached).删除必填字段时，也适用同样的情况.

Let me explain more of the reasoning why required fields should be used sparingly. If you are already using a proto, you can't add a required field because old application's won't be providing that field and applications in general don't handle the failure well. You can make sure that all old applications are upgraded first, but it can be easy to make a mistake and it doesn't help if you are storing the protos in any datastore (even short-lived, like memcached). The same sort of situation applies when removing a required field.

显然"需要很多必填字段，直到...它们不是必需的.假设您有一个Get字段用于Get方法.这显然是必需的.除外，稍后您可能需要将id从int更改为字符串，或者将int32更改为int64.这就需要添加一个新的muchBetterId字段，现在剩下必须指定 的旧的id字段，但最终将被完全忽略.

Many required fields were "obviously" required until... they weren't. Let's say you have an id field for a Get method. That is obviously required. Except, later you might need to change the id from int to string, or int32 to int64. That requires adding a new muchBetterId field, and now you are left with the old id field that must be specified, but eventually is completely ignored.

当这两个问题结合在一起时，有益的required字段的数量就变得有限，并且各阵营都在争论它是否仍然有价值. required的反对者不一定反对这个想法，而是它的当前形式.一些人建议开发一种更具表现力的验证库，该库可以检查required以及诸如name.length > 10之类的更高级内容，同时还应确保具有更好的故障模型.

When those two problems are combined, the number of beneficial required fields becomes limited and the camps argue over whether it still has value. The opponents of required weren't necessarily against the idea, but its current form. Some suggested developing a more expressive validation library that could check required along with something more advanced like name.length > 10, while also making sure to have a better failure model.

Proto3总体上看似更喜欢简单性，而required的删除更简单.但是，也许更令人信服的是，与其他功能结合使用时，删除required对于proto3是有意义的，例如，删除基元的字段存在和删除覆盖的默认值.

Proto3 overall seems to favor simplicity, and required removal is simpler. But maybe more convincing, removing required made sense for proto3 when combined with other features, like removal of field presence for primitives and removal of overriding default values.

我不是protobuf开发人员，也不是这个问题上的权威，但是我仍然希望这种解释是有用的.

I'm not a protobuf developer and am in no way authoritative on the subject, but I still hope that the explanation is useful.

这篇关于为什么在协议缓冲区3中删除了必需和可选的内容的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！