ユーザーによる編集の適用方法

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

アクションでオブジェクトを編集する

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

アクションがオブジェクト、リンク、またはオブジェクトセットに適用されると、データ変更ロジックがオブジェクトデータベース内のインデックスに即座に適用されます。その後、Funnel が所有および管理する Foundry データセットの形式で、永続ストアに定期的に書き出されます。詳細は、ユーザーによる編集の永続ストレージに関するドキュメントを参照してください。

ライブデータに対するユーザーによる編集

アクションがトリガーされると、Actions サービスは変更指示を Funnel サービスに送信します。この指示は、ユーザーによる同時編集をサポートするためにオフセットを追跡する、Funnel 管理のキューに保存されます。Object Storage v2 は、すべてのオブジェクトタイプと、結合テーブルを持つすべての多対多リンクタイプについて、これらのオフセットを追跡します。オフセットは、オブジェクトデータベース内のライブのインデックス化済みデータに適用されます。オントロジークエリの一環として行われるオブジェクトの読み取りが、ユーザーによる変更の送信後に発生した場合、その読み取り結果にはユーザーによる編集が含まれることが保証されます。

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

ユーザーによる編集がすでに含まれているデータは、ユーザーが追加で編集することでのみ更新できます。オブジェクトを更新または再作成するためにユーザーが追加で編集する（たとえば、オブジェクトアクションを使用する）以外に、ユーザーによる個々の編集や削除を直接元に戻す仕組みはありません。

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

Object Storage v2 は、ユーザーによる編集を移行するためのスキーマ移行フレームワークを提供します。「すべての編集を削除」指示を使用すると、オブジェクトタイプに対する既存のユーザー編集をすべて破棄できます。この移行指示は、Ontology Manager のデータソースタブの編集セクションにある編集を削除ボタンをクリックすると適用できます。

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

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

アクションを適用する過程では、アクションの検証、関数、アクションの副次的効果など、さまざまな目的でオブジェクトタイプの定義とオブジェクトのインスタンスが読み込まれます。アクションの適用中にオブジェクトのインスタンスが変わる可能性があるため、データの正確性に関する潜在的な問題（誤ったバージョンのオブジェクトにアクションを適用するなど）を避けるには、トランザクション性を保証することが重要です。

オントロジーには、オブジェクトタイプとオブジェクトのインスタンスの両方についてバージョンの整合性を確認する仕組みがあります。その動作は、Object Storage v1 (Phonograph) と Object Storage v2 で異なります。

フロントエンドの利用側と Actions サーバー間のエンティティのバージョン管理

ユーザーがアクションフォームで、バージョン {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 サーバーが読み込まれたオブジェクトのバージョンを追跡し、アクションの実行中は常にキャッシュから同じバージョンを読み込みます。Object Storage v1 (Phonograph) でユーザーによる編集が適用されると、オブジェクトのバージョンがリクエストに含まれます。その後、Object Storage v1 (Phonograph) はオブジェクトのバージョンに変更がないか確認し、変更が検出された場合は StaleObject エラーをスローします。

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

Object Storage v2

Object Storage v2 では、Actions サーバーがユーザーによる編集を Funnel サービスに送信する前に、独自にオブジェクトのバージョンを確認します。ただし、Object Storage v1 (Phonograph) と比べて、サーバーが収集したバージョンのうち、確認対象は限られた一部のみです。

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

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

バックエンドをまたぐアクション

OSv1 と OSv2 のオブジェクトを同時に変更するアクションタイプは、「バックエンドをまたぐ」アクションタイプと見なされます。このような場合、Actions サービスは次の対象を確認します。

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

ユーザーによる編集の永続ストレージ

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

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

• オブジェクトタイプのデータソースに新しいデータトランザクションがあるたび
• データソースに新しいデータがない場合は、いずれかのオブジェクトに対する編集が検出されていれば、6時間ごと

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

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

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

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

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

この戦略では、同じオブジェクトの編集済みプロパティに対して、その後データソースからどのような更新があっても、オブジェクトの最終状態は常に、そのオブジェクトに適用されたユーザー編集によって決まります。

ユーザー編集とデータソース更新に基づいてオブジェクトの最新状態を判断するには、以下のフローチャートを参照してください。

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

戦略2：最新の値を適用する

この戦略では、ユーザー編集は条件付きで適用されます。つまり、ユーザー編集のタイムスタンプが、対象オブジェクトのデータソースから取得されるタイムスタンプ値よりも新しい場合にのみ、ユーザー編集が適用されます。各編集のタイムスタンプは、データソースから取得される未編集のタイムスタンプ値と比較されるため、同じオブジェクトでも、新しいユーザー編集の一部は適用され、古いユーザー編集は適用されない場合があります。

設定

競合解決戦略はオブジェクトタイプ単位で設定され、OSv2 オブジェクトタイプでのみサポートされます。

このオプションは、Ontology Manager のデータソースセクションで設定できます。オブジェクトタイプの各データソースには、異なる解決戦略を設定できます。たとえば、2個のデータソースに基づくオブジェクトタイプでは、一方のデータソースで「ユーザー編集を適用（デフォルト）」を使用し、もう一方で「最新の値を適用」を使用できます。「最新の値を適用」オプションを使用するには、データソースにタイムスタンプ型のプロパティが含まれている必要があります。日付のプロパティタイプは、このオプションには使用できません。タイムスタンププロパティは、比較を行い、ユーザー編集を適用するかどうかを判断するために使用されます。タイムスタンププロパティは協定世界時 (UTC) である必要があります。

動作

データソースの競合解決戦略として「最新の値を適用」を保存すると、そのデータソースに基づくプロパティへのすべてのユーザー編集が、直ちに条件付きで適用されるようになります。

条件付きの各編集について、元データソースのタイムスタンプ値と、編集に関連付けられたタイムスタンプを比較して解決します。競合解決戦略を変更した_後_にそれらのプロパティに対して行われたユーザー編集は、その編集を生じさせたアクション実行のタイムスタンプに基づいて条件付きで適用されます。また、それらのプロパティに対する_既存_の編集は、競合解決戦略を変更した時点のタイムスタンプに基づいて条件付きで適用されます。

元データソースのタイムスタンププロパティの値が、ユーザー編集に関連付けられたタイムスタンプよりも古い場合、ユーザー編集が適用されます。それ以外の場合、編集は無視されます。

1回の編集で複数のデータソースにまたがるプロパティが更新される場合、その編集が条件付きで適用されるか、常に適用されるかは、各プロパティの元データソースの解決戦略によって決まります。

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

次の例は、この動作を示しています。「最新の値を適用」オプションが有効になっている元データソースに、以下のデータを持つ Ticket オブジェクトタイプのオブジェクトが2個あるとします。

これらのチケットに対して、次の3回のアクションが実行されたとします。

• 2010年1月1日午前8:30に、両方のチケットのタイトルが「Ticket」に設定されました。
• 2010年1月1日午前9:30に、両方のチケットの優先度が「P0」に設定されました。
• 2010年1月1日午前10:30に、両方のチケットの種類が「Unknown」に設定されました。

この場合、オントロジー内の2個のオブジェクトは、次の状態で表示されます。

チケットIDが101のチケットでは、タイトルプロパティへの編集は適用されませんでした。これは、その編集が元データソースの午前9:00のタイムスタンプよりも前に作成されたためです。ただし、ほかの2個のプロパティへの編集は午前9:00よりも後に行われたため、解決後のオブジェクトに反映されます。

チケットIDが102のチケットでは、元データソースのタイムスタンププロパティに値がないため、関連付けられたタイムスタンプにかかわらず、3回の条件付き編集がすべて適用されます。

編集専用プロパティ

編集専用プロパティでは、入力データソースのタイムスタンプにかかわらず、ユーザー編集が常に適用されます。

上記のチケットの例に戻り、次のテーブルを考えます。

アクションタイプ「チームを変更」を使用して、Team プロパティを Recruiting に変更するとします。「チームを変更」アクションを Ticket Two に適用すると、チームは Recruiting に設定されます。競合解決にどの戦略を使用しているかにかかわらず、Team は編集専用プロパティであるため、編集が適用されます。

アクションで編集専用プロパティと通常のプロパティの両方を変更する場合も、動作は同じです。通常のプロパティへの編集は条件に基づいて適用されますが、編集専用プロパティへの編集は常に適用されます。

入力データソースの値のみを考慮

オントロジーは、編集のタイムスタンプを入力データソースのタイムスタンプ値とのみ比較します。ユーザー編集によってタイムスタンププロパティを変更した場合でも、条件の比較は、入力データソースのタイムスタンプとユーザー編集の適用時刻との間でのみ行われます。

この動作により、タイムスタンププロパティの元データは、入力データソースのタイムスタンプ列である必要があります。ソースシステムがデータフィードの更新時刻を示すタイムスタンプ値を提供しない場合は、データパイプライン内で入力データソースのタイムスタンプ列を変更できます。

上記のチケットの例に戻り、次のテーブルを考えます。

アクションタイプ「タイムスタンプを変更」を使用して、上記のチケットのタイムスタンプを January 1, 2050, 9:00 AM UTC に変更するとします。

ここで「優先度を変更」アクションを Ticket One に適用すると、優先度は引き続き P0 に設定されます。 オブジェクトに表示されているタイムスタンプにかかわらず、比較は入力データソースのタイムスタンプとユーザー編集の適用時刻との間でのみ行われます。