☰

プロトコル バッファ - 固有の番号付きタグ - 説明? 質問する

tag-icon • tag-icon protocol-buffers
プロトコル バッファ - 固有の番号付きタグ - 説明? 質問する

私はプロトコル バッファを使用しており、すべて正常に動作しています。ただし、ファイル内に番号付きタグが必要な理由がわかりませんproto。

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

もちろん読んだよドキュメント:

ご覧のとおり、メッセージ定義の各フィールドには一意の番号付きタグがあります。これらのタグは、メッセージのバイナリ形式でフィールドを識別するために使用され、メッセージ タイプが使用されると変更しないでください。

変更するとどのような違いが生じるのか理解できませんでした。(新しいプロトを作成してコンパイルするので、なぜそれが問題になるのでしょうか?)

別の記事では次のように述べられています。

proto 定義の番号付きフィールドにより、バージョン チェックの必要性がなくなります。これは、プロトコル バッファーの設計と実装の明確な動機の 1 つです。開発者向けドキュメントに記載されているように、プロトコルは、プロトコル バージョンをチェックするための次のような「醜いコード」を回避するために設計されました。

if (version == 3) {
  ...
} else if (version > 4) {
  if (version == 5) {
    ...
  }
  ...
}

質問

それは私だけでしょうか、それとも完全に不明瞭なのでしょうか?

別の言い方で聞いてみましょう:

上記のような proto ファイルがある場合、次のように変更します。

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

何を気にするのでしょうか? 再コンパイルしてファイルを追加します (先週、これを複数回行いました)。

何が足りないのでしょうか? この番号付きタグについて、人間同士で説明していただけますか?

ベストアンサー1

番号付きタグは、データをシリアル化および逆シリアル化するときにフィールドを一致させるために使用されます。

当然のことながら、番号付けスキームを変更し、この変更をシリアライザーとデシリアライザーの両方に適用すれば、問題は発生しません。

ただし、最初の番号付けスキームでデータを保存し、2 番目の番号付けスキームでロードした場合、queryにロードしようとするresult_per_pageため、逆シリアル化が失敗する可能性が高くなります。

さて、なぜこれが便利なのでしょうか? スキーマがすでに使用されている後、データに別のフィールドを追加する必要があるとします。

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

明示的に番号を指定すると、デシリアライザは、古い存在しないデータの逆シリアル化を無視する番号付けスキーム。

おすすめ記事