問題タブ [protocol-buffers]

Google Protocol Buffersを使用して、ビジネス オブジェクトの一部を (Java アプリで) シリアル化しています。チュートリアルで推奨されているように、メッセージのプロパティにアクセスするためのゲッター メソッドとセッター メソッドを実装する独自のクラスにメッセージ ビルダーをラップします。また、すべてのメッセージ フィールドを宣言しましたがoptional、ここでも推奨事項に従っています。

これで、任意のラッパー クラスに任意のエンコードされたメッセージを渡すことができ、それらは常にそれらを解析して受け入れます。これにより、実際には含まれていないメッセージ タイプを表すラッパー オブジェクトが生成され、多くの偽物が発生します。

メッセージのバイナリ コンテンツをラッパー クラスにロードするときに、間違った型が渡された場合にエラーを発生させるにはどうすればよいですか?

私が現在考えている解決策は、すべてのメッセージが必要なタイプ フィールド (およびおそらくバージョン フィールド) を持つ基本メッセージを拡張することです。これにより、これらのフィールドが欠落している場合、生成されたビルダー クラスが例外をスローし、それらが存在する場合は、自分のコードをチェックインできます。ただし、これが私のコードにどのような影響を与えるかの評価はまだ完了しておらず、これが簡単になるかどうかもわかりません。

Marc Gravellによって開発された .NET 用のプロトコル バッファ ソリューションがなぜこれほど高速なのかを理解したいと思います。

元の Google ソリューションがどのようにパフォーマンスを達成したかは理解できます。オブジェクトのシリアル化用に最適化されたコードを事前に生成します。私はいくつかのシリアル化を手作業で書きましたが、リフレクションを回避すれば、この方法で非常に高速なコードを記述できることを知っています。しかし、Marc のライブラリは、属性を使用するランタイム ソリューションであり、コードを生成しません。それで、それはどのように機能しますか？

データを保存し、プロトコル バッファを使用してサーバーと通信する Android アプリケーションを作成しています。ただし、LITE フラグを使用してコンパイルされたプロトコル バッファのストック実装(JAR ライブラリと生成された .java ファイルの両方) には、最大 30 KB のオーバーヘッドがあり、プログラム自体は最大 30 KB しかありません。つまり、プロトコル バッファはプログラム サイズを 2 倍にします。

オンラインで検索すると、 Android 固有の実装への参照が見つかりました。残念ながら、それに関するドキュメントはないようで、標準の .proto ファイルから生成されたコードはそれと互換性がありません。誰かがそれを使用しましたか？この実装の .proto ファイルからコードを生成するにはどうすればよいですか? 他に軽量の代替品はありますか？

ドキュメンテーションをざっと見た後、すぐに既存の言語やアプリケーションとの統合について考え始め、Protocol Buffers のサポートが提供されるかどうか疑問に思っていました。

以下のプロトコルバッファがあります。StockStatic は繰り返しフィールドであることに注意してください。

ベクトルを繰り返し処理しながら、StockStatic フィールドに入力しています。

ただし、上記のコードが正しいのは、StockStatic がオプション フィールドであり、繰り返しフィールドではない場合のみです。私の質問は、繰り返しフィールドにするために欠落しているコード行は何ですか?

Google Protocol Buffers と GWT を一緒に使用する例を知っていますか?

一部のバックエンドRPCサービスの新しいトランスポートとしてプロトコルバッファを導入しています。異なる形式の類似したオブジェクト間でデータを手動でシャトルすることには抵抗があるため、RPCサーバーインターフェイスよりも少し高い位置でプロトコルバッファインスタンスがスタックに渡されることがわかります。

これは私が避けなければならないことですか？プロトコルバッファオブジェクトをプレーンなデータホルダーのように扱うのは安全ですか？それはバイナリにすばやく効率的に変換でき、バイナリから変換できるという便利な機能がありますか？

データオブジェクトを生成するための優れた方法であると私が考えるもう1つの理由は、必須/オプションのフィールドと自動的に生成されたビルダーインターフェイスの概念です。

部分的なシリアル化をサポートする既存の優れた C++ シリアル化ライブラリはありますか?

「部分的なシリアル化」とは、3 つの特定のメンバーの値を保存し、後でその保存されたコピーを別のインスタンスに適用できるようにすることを意味します。これらの 3 つのメンバーのみを更新し、他のメンバーはそのままにしておきます。

これは、ネットワークを介してデータを同期するのに役立ちます。クライアントとサーバーにオブジェクトがあり、サーバーでメンバーが変更されたときに、そのメンバーとそのメンバーのみの更新された値を含むメッセージをクライアントに送信したいとします。オブジェクト全体のコピーをネットワーク経由で送信したくありません。

boost::serialization一見すると、すべてまたはまったくサポートしていないように見えます。

編集: 最初にこれを書いてから 3 年後、私はそれを振り返って、自分自身に言います。boost::serialization を使用すると、保存するメンバーと保存しないメンバーを定義できるため、説明したように「部分的なシリアル化」をサポートします。さらに、C++ にはリフレクション シリアライゼーション ライブラリがないため、保存する各メンバーを明示的に指定する必要があります。ただし、ソース ファイルを解析するための何らかの外部ツールが付属している場合や、C++ コードの生成に使用される別の入力ファイル形式がある場合を除きます (例: Protocol Buffers の機能)。これを書いたとき、私は概念的に混乱していたに違いないと思います。

protobufクラスから生成されたPythonコードを使用すると、次のエラーが発生します。

同等のC++で生成されたコードは問題なく機能するため、実際のプロト定義に問題はないように見えます。

このエラーは、次のようにクラスをインポートしようとすると発生します。

システムパスを追加するのは正しいですか？

protobuf\python\google\protobufディレクトリをチェックインしましたdescriptor_pb2.pyが、見つかっただけdescriptor.pyです。最新バージョンを使用しているため、不足しているファイルはないと思います。

誰かが解決策が何であるか知っていますか？

app-engine-patchプロジェクトの背後にいる賢い人々は、基本的に、管理者を含むDjangoのすべての楽しい機能を有効にしましたが、DjangoのORMを使用していません。

彼らのウェブサイトから：

最も重要な変更は、開発モデルがDjangoとはあまりにも異なるため（少なくともDjangoの現在のAPIでは）、 GoogleのModelクラスを使用する必要があることです。

これは基本的に私がやりたいことですが、RPCを介したデータトランスポート層としてGoogleのプロトコルバッファを使用します。

addressbook.protoの例でPersonメッセージを使用して、基本的にこれを実行したいと思います。