ユーザー編集の適用方法

ユーザー編集は、オントロジー・マネージャーの Datasources タブにある Edits トグルを使用して有効化および無効化できます。以下のスクリーンショットに示すようになります。

アクションを介したオブジェクトの編集

このセクションでは、オントロジーがアクションを使ってオブジェクトの編集を管理する方法について説明します。

アクションがオブジェクト、リンク・インスタンス、またはオブジェクト・セットに適用されると、データ変更ロジックはオブジェクト・データベースのインデックスに直ちに適用され、定期的に Funnel が所有および管理する Foundry データセットの形で永続ストアにフラッシュされます。詳細は、persistent storage of user edits のドキュメントを参照してください。

ライブデータ上のユーザー編集

アクションがトリガーされると、アクションサービスは Funnel サービスに変更指示を送信します。この指示は、同時ユーザー編集をサポートするオフセット追跡を持つ Funnel 管理キューに格納されます。Object Storage V2 は、オブジェクト・タイプや多対多リンク・タイプに関連する結合テーブルを持つすべてのオフセットを追跡します。オフセットはオブジェクト・データベースのライブ・インデックスデータに適用され、オントロジー・クエリの一部として行われるオブジェクト・リードがユーザー変更後に行われる場合、オブジェクト・リードにはユーザー編集が含まれることが保証されます。

既存のユーザー編集を破棄/削除する方法

ユーザー編集は、入力データソースよりも優先されることが、Resolving conflicts セクションでさらに説明されています。したがって、ユーザー編集が含まれるデータを更新するには、ユーザー編集も行う必要があります。単一のユーザー編集や削除を元に戻すメカニズムはありませんが、代わりに追加のユーザー編集（例：オブジェクト・アクション）を行ってオブジェクトを更新したり、再作成したりすることができます。

特定の状況下では、すべてのオブジェクト・インスタンスの状態を入力データソースと同じ状態にリセットするために、すべての既存のユーザー編集を破棄することが望ましい場合があります。例えば、オブジェクト・タイプを本番環境でリリースする前に、オブジェクト・タイプのテスト中に適用されたすべてのユーザー編集を削除することが考えられます。

Object Storage V2 は、ユーザー編集を移行するための schema migration framework を提供しています。"drop all edits" インストラクションを使って、オブジェクト・タイプの既存のユーザー編集をすべて破棄することができます。この移行指示は、オントロジー・マネージャーの Datasources タブの Edits セクションにある Delete edits ボタンをクリックすることで適用できます。

Object Storage V1 (Phonograph) は、スキーマ移行のサポートがありませんが、オブジェクト・タイプ定義から書き戻しデータセット構成を削除すると、既存のユーザー編集がすべて削除されるため、回避策として使用できます。

オントロジー・エンティティのバージョン管理

アクションを適用する過程で、オブジェクト・タイプのメタデータ情報やオブジェクト・インスタンス・データが、アクションの検証、Functions、アクション side effects などの目的でロードされます。オブジェクト・インスタンスは、アクションを適用する過程で変更される場合があり、トランザクション性を保証することが重要です（例：アクションをオブジェクト・インスタンスの誤ったバージョンに適用するなどのデータ正確性の問題を避けるため）。

オントロジーには、オブジェクト・タイプとオブジェクト・インスタンスのバージョンの両方のバージョン一貫性をチェックするメカニズムが含まれており、Object Storage V1 (Phonograph) と Object Storage V2 の間で異なる動作があります。

フロントエンド消費者とアクションサーバー間のエンティティバージョン管理

以下のシナリオを考えてみましょう。ユーザーは、Action form でバージョン {V1, V2, V3, ...} のオブジェクト・インスタンス・パラメーターをロードします。フロントエンドの消費者アプリケーションは、これらのオブジェクト・パラメーターを持つアクションサーバーの /apply エンドポイントを呼び出しますが、そのリクエストにはバージョンが含まれません。このリクエストを受け取ったアクションサーバーは、/apply エンドポイント内でバージョン {V1', V2', V3', ...} のオブジェクトをロードします。フロントエンドでロードされたバージョン {V1, V2, V3, ...} と、アクションサーバーによってロードされたバージョン {V1', V2', V3', ...} が常に同じであることを保証するものではありません。

アクションサーバー内のエンティティバージョン管理

Object Storage V1 (Phonograph)

Object Storage V1 (Phonograph) では、アクションサーバーはロードされたオブジェクトのバージョンを追跡し、アクションの実行中にキャッシュから同じバージョンをロードします。ユーザー編集が Object Storage V1 (Phonograph) に適用されると、リクエストにオブジェクトのバージョンが含まれます。Object Storage V1 (Phonograph) は、オブジェクトのバージョンが変更されたかどうかをチェックし、変更が検出された場合には StaleObject エラーをスローします。

これらのチェックは、アクションサーバー内で一般的な整合性を保証します。たとえば、Object Storage V1 は、アクションが同期 webhook を生成し、実行し、検証し、オブジェクトの同じバージョンに編集を適用することを保証しています。ただし、プロパティレベルでのオブジェクトの変更はチェックされないため、オブジェクトの無関係なプロパティに対するユーザー編集が StaleObject の競合を引き起こす可能性があります。

Object Storage V2

Object Storage V2 では、アクションサーバーは Funnel サービスにユーザー編集を投稿する前に、オブジェクトのバージョンチェックを独自に実行しますが、Object Storage V1 (Phonograph) で収集されるバージョンのサブセットに対して限定的なバージョンチェックを行います。

アクションサーバーは、編集を生成するために直接使用されるオブジェクトのバージョンのみをチェックします。例えば、あるオブジェクト A のプロパティがオブジェクト B にコピーされたバージョンなど、これらのバージョンは、編集されたオブジェクトバージョンとのみ比較されます。

この挙動は、StaleObject の競合の頻度を減らしますが、OSv2 での保証が弱くなる結果となります。Object Storage V2 では、アクションサービスは常にアクション /apply 中に同じバージョンのオブジェクトをロードしますが、編集生成以外のオブジェクトの読み取りがアクションの過程で変更されていないことを保証しません。

クロスバックエンドアクション

アクションタイプが OSv1 と OSv2 の両方でオブジェクトを同時に変更する場合、「クロスバックエンド」と見なされます。このような場合、アクションサービスは次のオブジェクトに対してチェックを実行します。

• OSv1 で読み取られたおよび/または編集されたすべてのオブジェクト、および
• OSv2 で編集されたすべてのオブジェクト。

ユーザー編集の永続的な保存

オブジェクトデータベースのすべてのインデックスデータは、一時的なものと見なされ、オントロジーデータを他の方法で永続的に保存する必要があります。同様に、アクションを介したユーザー編集も永続的に保存する必要があります。オブジェクトタイプをバックアップする Foundry データソースは、Foundry データセット、制限付きビューなどの形で既に永続的に保存されています。

Funnel pipelines documentation で説明されているように、Funnel サービスは、データソースからのデータとユーザー編集を組み合わせたマージされたデータセットを含む、いくつかの Foundry データセットを所有および管理しています。マージされたデータセットは自動的に構築され、キューに保存されたユーザー編集が Foundry で永続的に保存され、キューが大きくなりすぎるのを防ぐためにキューが空になることが保証されます。デフォルトでは、このビルドジョブは次のタイミングでトリガーされます。

• オブジェクトタイプデータソースで新しいデータトランザクションがある場合、または
• データソースに新しいデータがない場合で、6時間ごとに、オブジェクトで編集が検出された場合。

ユーザー編集とデータソース更新の競合を解決する

Foundry オントロジーのオブジェクト・インスタンスは、入力データソースとユーザー編集の両方によって作成および変更されることがあります。特定の主キー値を持つ単一のオブジェクト・インスタンス（つまり、行またはオブジェクト）が入力データソースとユーザー編集の両方からデータを受け取る場合、これらの受け取った値は、競合解決戦略 を使って透過的に解決する必要があります。 対立解決のための2つの戦略があります。

• 戦略 1: ユーザー編集を適用する（デフォルト）
• 戦略 2: 最新の値を適用する（限定ベータ）

戦略 1: ユーザー編集を適用する（デフォルト）

この戦略では、オブジェクトインスタンスの最終状態は、同じオブジェクトインスタンスに対するデータソースの今後の更新に関係なく、それに適用されたユーザー編集によって常に決定されます。

ユーザー編集とデータソースの更新に基づいてオブジェクトインスタンスの最新の状態を決定するための下のフローチャートを参照してください。

以下の表は、特定のオブジェクトインスタンスが「ユーザー編集が常に勝つ」対立解決戦略に従って、ユーザー編集と入力データソースの更新を受け取った後にどのように更新されるかを示しています。

戦略 2: 最新の値を適用する（限定ベータ）

この戦略では、ユーザー編集は条件付きで適用されます。つまり、ユーザー編集は、データソースからのタイムスタンプ値が与えられたオブジェクトインスタンスよりも新しい場合にのみ適用されます。

設定

対立解決戦略は、オブジェクトタイプレベルで設定され、単一の入力データソースを持つ OSv2 オブジェクトタイプでのみサポートされます。

ユーザーは、オントロジーマネージャーの Datasources セクションでこのオプションを設定できます。最新の値を適用する オプションでは、オブジェクトタイプにタイムスタンプタイプのプロパティを含める必要があります。日付プロパティタイプは、このオプションでは機能しません。タイムスタンププロパティは、ユーザー編集が適用されるべきかどうかを決定するための比較に使用されます。

挙動

オブジェクトタイプに対して 最新の値を適用する 対立解決戦略が保存されると、すぐに_今後の_ユーザー編集が条件付きで適用されます。これは、オブジェクトインスタンスに存在するタイムスタンプと、適用された最新のユーザー編集のタイムスタンプを比較することで機能します。オブジェクトのタイムスタンプがユーザー編集時間よりも古い場合にはユーザー編集が適用され、そうでない場合には無視されます。

ユーザー編集とデータソースの更新に基づいてオブジェクトインスタンスの最新の状態を決定するための、下の更新されたフローチャートを参照してください。

以下の例は、この挙動を説明しています。チケット オブジェクトタイプの3つのオブジェクトインスタンスが以下のデータであると仮定します。ここで、最新の値を適用する オプションが有効になっており、チケットの優先度を P0 に変更するアクションタイプ Change Priority があります。

• Change Priority アクションが Ticket One に適用された場合、ユーザー編集がデータソースからのタイムスタンプ値の後に来るため、優先度は P0 に設定されます。
• Change Priority アクションが Ticket Two に適用された場合、ユーザー編集がデータソースからのタイムスタンプ値の前に来るため、優先度は P2 のままです。
• Change Priority アクションが Ticket Three に適用された場合、データソースからのタイムスタンプ値が存在しない場合は常にユーザー編集が適用されるため、優先度は P0 に設定されます。

入力データソースの値のみが考慮される

オントロジーは、入力データソースからのタイムスタンプとユーザー編集の適用時間との間でのみタイムスタンプを比較することに注意してください。ユーザーがユーザー編集を介してタイムスタンププロパティを変更しても、条件付きの比較は入力データソースからのタイムスタンプとユーザー編集の適用時間の間でのみ行われます。

この挙動の結果として、タイムスタンププロパティは入力データソースのタイムスタンプ列によってバックアップされなければなりません。ソースシステムがデータフィードの更新時間を示すタイムスタンプ値を提供しない場合、データパイプライン内の入力データソースのタイムスタンプ列を変更できます。

上記のチケットの例に戻ります。以下の表を考慮してください。

アクションタイプ Change Timestamp が使われて、上記のチケットのタイムスタンプを 2050年1月1日 に変更すると仮定します。

これで、Ticket One に Change Priority アクションが適用された場合、優先度はまだ P0 に設定されます。 オブジェクトインスタンスに表示されるタイムスタンプに関わらず、比較は入力データソースからのタイムスタンプとユーザー編集の適用時間の間でのみ行われます。