最近、gRPCを使用していますが、新しい構文ではと が削除されているproto3ことに気付きました。requiredoptional
proto3 で required/optional が削除されている理由を誰か親切に説明してくれませんか? 定義を堅牢にするためには、このような制約が必要なようです。
構文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;
}
ベストアンサー1
の有用性は、required多くの議論や激しい論争の中心となってきました。どちらの側にも大きな陣営が存在していました。一方の陣営は、値が存在することを保証し、その制限を受け入れることを好みましたが、もう一方の陣営は、required安全に追加も削除もできないことから、危険または役に立たないと感じていました。
フィールドを控えめに使用する必要がある理由をもう少し説明しましょうrequired。すでに proto を使用している場合は、必須フィールドを追加できません。古いアプリケーションではそのフィールドが提供されず、アプリケーションは一般に障害にうまく対応できないためです。古いアプリケーションをすべて最初にアップグレードすることはできますが、間違いを犯しやすい可能性があり、proto を任意のデータストア (memcached のように短命であっても) に保存している場合は役に立ちません。必須フィールドを削除する場合も、同様の状況が当てはまります。
多くの必須フィールドは、以前は「明らかに」必須でしたが、今では必須ではなくなりました。メソッドidのフィールドがあるとします。Getこれは明らかにid必須です。ただし、後でint から string に、または int32 から int64 に変更する必要がある場合があります。そのためには新しいフィールドを追加する必要があり、指定する必要のある古いフィールドmuchBetterIdが残りますが、最終的には完全に無視されます。id
これら 2 つの問題が組み合わさると、有益なフィールドの数requiredが限られ、両陣営はそれがまだ価値があるかどうかについて議論します。 の反対者は、必ずしもアイデアに反対しているのではなく、その現在の形式に反対しているのです。のようなより高度なものと一緒にrequiredチェックできる、より表現力豊かな検証ライブラリを開発し、同時により優れた失敗モデルを確保することを提案する人もいました。requiredname.length > 10
Proto3 は全体的にシンプルさを重視しているようで、required削除の方が簡単です。しかし、おそらくもっと説得力があるのは、requiredプリミティブのフィールドの存在の削除やオーバーライドするデフォルト値の削除など、他の機能と組み合わせた場合に Proto3 の削除が理にかなっているということです。
私は protobuf 開発者ではなく、この件に関して権威があるわけではありませんが、それでもこの説明が役に立つことを願っています。