Microsoft BondランタイムschemaDef

Question

誰かがMicrosoft Bondランタイムスキーマ（SchemaDef）の一般的な使用例を説明できることを期待しています。私は、スキーマ定義がコンパイル時にわからないときにこれらが使用されることを理解していますが、オブジェクトの形状が流動的で頻繁に変化する場合、実行時に生成されるスキーマはどのようなメリットをもたらしますか？

私の使用例は、ビジネスユーザーが（ルールエンジンを介して）オブジェクトの形を制御していることです。彼らは、下位互換性を損なう可能性のあるあらゆる種類の事柄を考え出すことができます（例えば、オブジェクトのフィールドの順序を逆転させるなど）。ユーザーが作成したすべてのオブジェクトバージョンを永続化する予定の場合は、Bondランタイムスキーマを使用して、後方/前方互換性を管理する方法はありますか？

0: string myString; 
1: int64 myInt; 

この

に

0: int64 myInt; 
1: string myString; 

私はランタイムエラーを期待したい：私は、彼らがこのことから反転しているかのよう、ない推測します。これは、ランタイムスキーマでオブジェクトを管理することは、私にはあまり役に立たないことを意味します。

実行時スキーマが実際に役に立つユースケースは何でしょうか？

ありがとうございました！

Answer 1

ランタイム・スキーマのための用途のいくつかは以下のとおりです。スキーマを処理するための単純なバイナリプロトコルで

• はからGUI
• カスタムマッピングで構造体をレンダリング
• スキーマ検証を変更/ evoluton
• 他の構造体への1つの構造体

あなたのケースでは、積極的にscheを拒否できれば、スキーマ検証のように感じますそれは互換性がありません。私はフードの下でボンドを使用し、このアプローチをとったシステムに取り組んだ。 2つのスキーマが互いに互換性があるかどうかを検証する明示的な「このエンティティのスキーマの変更」操作がありました。

システムのデータフローがわからないため、このような検証はできない可能性があります。その場合、ランタイムスキーマをビジネスユーザーが提供するいくつかのルールとともに使用して、異なる形状間で変換することができます。

単純なバイナリ

単純なバイナリから逆シリアル化する、読者はそれ以外の場合は、潜在的にサイレントデータ破損が生じ、バイトを解釈する方法がない、正確なスキーマ作家が使用したを知っている必要があります。 Foo { f1: 1, f2: 2}の単純なバイナリシリアル化された表現は0x01 0x02 0x00ある

// starting struct 
struct Foo 
{ 
    0: uint8 f1; 
    1: uint16 f2; 
} 

：スキーマは、以下の変化を受けている場合

このような破損が発生する可能性があります。

は、今度はこれにスキーマを変更してみましょう：

// changed struct 
struct Foo 
{ 
    0: uint8 f1; 
    // It's OK to remove an optional field. 
    // 1: uint16 f2; 
    2: uint8 f3; 
    3: uint8 f4; 
} 

私たちは、このスキーマで0x01 0x02 0x00をデシリアライズした場合、我々はを取得します。f3が2であることは正しくありません。古いFooのランタイムスキーマでは、2番目と3番目のバイトは削除されたフィールドに対応しているため、スキップすることができます予想通り。Foo { f1:1, f3: 0, f4: 0 }。

スキーマ検証と進化

ボンドを使用するいくつかのシステムは、通常の債券ルールそのスキーマの進化のための異なるルールを持っています。ランタイムスキーマは、所与のタイプの構造体を受け入れる前に、またはそのようなスキーマを、例えば既知のスキーマのリポジトリに登録する前に、そのようなルール（例えば、コレクションが使用されないルールを強制するためにタイプをチェックする）を実施するために使用され得る。

また、2つのスキーマを歩いて、互いに互換性があると判断することもできます。 BondがそのようなAPI自体を提供していれば、何度も何度も再実装する必要はありません。私はGitHub issue for such an APIを開いた。ランタイム・スキーマで

GUI

、あなたはフィールドの名前のようなものを含む構造体に関する追加の情報を、持っています。バイナリエンコーディングプロトコルでは、フィールドIDにフィールド名を使用する必要はありません。この追加情報を使用して、各フィールドに固有のGUIコントロールを作成することができます。

実行時スキーマの検査を示す例がC#とC++です。 C++、MapToで

カスタムマッピング

変換ルールのセットを所与不適合なその形状、別の構造体に変換するために使用することができます。 an example of thisがあり、実行時スキーマを使用してルールが導出されます。