ユーザー編集の適用方法

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

Actions を介してオブジェクトを編集する

このセクションでは、Ontology が Actions を使用してオブジェクトの編集をどのように管理するかを説明します。

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

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

Action がトリガーされると、Actions サービスは Funnel サービスに修正指示を送信します。この指示は、同時ユーザー編集をサポートするためのオフセットトラッキングを備えた Funnel 管理キューに格納されます。Object Storage V2 は、任意のオブジェクトタイプおよび多対多リンクタイプの結合テーブルのオフセットを追跡します。オフセットはオブジェクトデータベースのライブインデックスデータに適用されます。ユーザー修正が送信された後にオントロジークエリの一部としてオブジェクト読み取りが発生する場合、そのオブジェクト読み取りにはユーザー編集が含まれていることが保証されます。

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

既にユーザー編集が含まれているデータは、追加のユーザー編集によってのみ更新できます。オブジェクトを更新するために追加のユーザー編集（たとえば、オブジェクトアクション）を行うか、オブジェクトを再作成する以外に、単一のユーザー編集や削除を直接元に戻すメカニズムはありません。

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

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

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

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

Action の適用プロセス中に、オブジェクトタイプメタデータ情報とオブジェクトインスタンスデータがさまざまな目的で読み込まれます。たとえば、Action の検証や Functions、および Action の side effects などです。Action の適用中にオブジェクトインスタンスが変更される可能性があるため、トランザクション性を保証して、データの正確性に関する問題（たとえば、間違ったバージョンのオブジェクトインスタンスに Action を適用するなど）を回避することが重要です。

Ontology には、オブジェクトタイプとオブジェクトインスタンスバージョンのバージョン整合性をチェックするためのメカニズムが含まれており、Object Storage V1 (Phonograph) と Object Storage V2 では異なる動作をします。

フロントエンドコンシューマーと Actions サーバー間のエンティティバージョン管理

ユーザーが Action form でバージョン {V1, V2, V3, ...} のオブジェクトインスタンスパラメーターを読み込む次のシナリオを考慮してください。フロントエンドコンシューマーアプリケーションは、そのオブジェクトパラメーターを使用して Actions サーバーの /apply エンドポイントを呼び出しますが、そのリクエストにはバージョンが含まれていません。このリクエストを受け取ると、Actions サーバーは /apply エンドポイント内でバージョン {V1', V2', V3', ...} のオブジェクトを読み込みます。フロントエンドで読み込まれたバージョン {V1, V2, V3, ...} と Actions サーバーによって読み込まれたバージョン {V1', V2', V3', ...} が常に同じであるという保証はありません。

Actions サーバー内のエンティティバージョン管理

Object Storage V1 (Phonograph)

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

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

Object Storage V2

Object Storage V2 では、Actions サーバーは Funnel サービスにユーザー編集を投稿する前に独自のオブジェクトバージョンチェックを実行しますが、サーバーによって収集されたバージョンのサブセットに対してのみチェックを行います。これは Object Storage V1 (Phonograph) と比較して制限があります。

Actions サーバーは、編集を生成するために直接使用されるオブジェクトのバージョンのみをチェックします。たとえば、オブジェクト A のプロパティがオブジェクト B にコピーされた場合、そのバージョンのみがチェックされます。これらのバージョンは編集されたオブジェクトのバージョンに対してのみチェックされます。

この動作により StaleObject の競合の頻度が減少しますが、OSv2 では保証が弱くなります。Object Storage V2 では、Actions サービスは Action /apply の間は常に同じバージョンのオブジェクトを読み込みますが、Action の実行中に編集生成の外で読み取られたオブジェクトが変更されていないことを保証しません。

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

Action タイプが OSv1 と OSv2 のオブジェクトを同時に変更する場合、その Action タイプは「クロスバックエンド」と見なされます。このような場合、Actions サービスは次のチェックを行います。

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

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

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

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

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

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

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

競合を解決するための戦略は 2 つあります。

• 戦略 1: ユーザー編集を適用（デフォルト）
• 戦略 2: 最新値を適用

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

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

ユーザー編集およびデータソース更新に基づいてオブジェクトインスタンスの最新状態を決定するためのフローチャートを以下に示します。

以下の表は、「ユーザー編集が常に優先する」という競合解決戦略に従って、特定のオブジェクトインスタンスがユーザー編集および入力データソースの更新を受け取った後の状態を示しています。