14

サーバーがシリアル化されたオブジェクトをprotobuf形式でクライアントに送信するクライアントサーバーアプリケーションがあり、requiredフィールドを廃止したいと思います。.proto残念ながら、新しい定義を使用するためにクライアントとサーバーの両方を同時に変更することはできません。

requiredフィールドをに変更した場合、メッセージをシリアル化optionalするコードのみ（つまり、逆シリアル化コードが再構築されておらず、それがフィールドであると見なされる場合） 、値を入力する限り、逆シリアル化できるメッセージを公開し続けることができます。今-フィールド？requiredoptional

（少なくとも私が実験したいくつかの些細なケース（Javaのみを使用）ではそうすることは問題ないようですが、それが一般的に賢明なアプローチであるかどうか、そしてエッジケースなどがあるかどうかについて心配する必要があります）。

動機：私の目標はrequired、サーバーがクライアントによって逆シリアル化されたメッセージを公開するクライアントサーバーアプリケーションのフィールドを廃止することです。私の意図するアプローチは次のとおりです。

  1. トランクのrequiredフィールドをに変更します。optional
  2. （関連のない機能/修正のために）新しいサーバーコードを展開する必要がある場合は、オプションのフィールドがメッセージに引き続き入力されていることを確認してください。
  3. すべてのクライアントに更新されたコードを段階的に展開します（独自のリリーススケジュールを持つ他のチームの関与が必要になるため、これには時間がかかります）
  4. すべてのクライアントが更新されたことを確認します。
  5. オプションフィールドの廃止（つまり、入力しない）を開始します。
4

2 に答える 2

22

エンコード形式のドキュメントによると、フィールドが必須かどうかは、シリアル化されたバイトストリーム自体にエンコードされていません。つまり、optionalまたはrequiredエンコードされたシリアル化されたメッセージに違いはありません。

実際には、Javaで生成されたコードを使用して、シリアル化されたメッセージをディスクに書き込み、出力を比較することで、これを確認しました。サポートされているすべてのプリミティブ型と他の型を表すフィールドを含むメッセージを使用します。

于 2012-12-03T00:42:03.720 に答える
3

フィールドが設定されている限りparseFrom(byte[])、byte []は同じであるため、このメソッドを使用して逆シリアル化することはできます。

ただし、オプションにする準備ができるまで、フィールドを必須からオプションに変更するのはなぜだろうか。基本的には、.protoファイルで「オプション」にするだけですが、常に入力することで必須にすることを強制しています。ちょっとした考え。

于 2012-12-03T00:34:02.167 に答える