ドキュメントの検索
karat

+

K

APIリファレンス ↗
8. [Repositories] オントロジーデータパイプライン32 - 元データセットの破壊的な変更:パート 2
Feedback

注: 以下の翻訳の正確性は検証されていません。AIPを利用して英語版の原文から機械的に翻訳されたものです。

32 - 元データセットの破壊的な変更:パート 2

📖 タスクの概要

登録済みのテーブルとインデックスをどのように修復するか? 行の削除や型の変更を伴う元データセットへの破壊的な変更が行われた場合、ユーザーはマッピングからプロパティを削除し、Phonograph のテーブル登録を更新する必要があります。これにより、新しいテーブルの再インデックスが開始されます。簡潔に言えば、修正のワークフローは次の通りです:

  1. 削除された行をアンマップします。
  2. ユーザーのオントロジーを保存します。
  3. テーブル登録を更新します。

⚠️ 警告: ユーザーの元データセットに対する「破壊的な」スキーマ変更は、アクション(またはそれ以外の方法)を通じて行われた編集を失う可能性があります。データ損失を避けるためには、このタスクの最後にある推薦文献を参照してください。

🔨 タスクの説明

  1. OMA で、ユーザーのフライトアラートオブジェクトタイプのプロパティマッピングインターフェースに進みます。
  2. マッピングの右側から rule_name プロパティを削除します。

  1. ユーザーのオントロジーを保存します。
  2. ユーザーのオブジェクトタイプに戻り、左側のパネルで Datasources メニューアイテムをクリックします。
  3. Phonograph セクションまでスクロールダウンし、Update ボタンをクリックします。これにより、新しい元データセットスキーマを持つ Phonograph テーブルが再読み込みされます。
    • 元データセットと Object Storage サービス(Phonograph)間の同期が修復されました。

ここでは例を示しませんが、破壊的な変更が元データセットの行の の変更(例:タイムスタンプから日付へ)の場合、処理は少し異なります。その場合、次のように行います:

  1. Properties メニューからそのプロパティの Base Format を更新します(以下の画像では date 型への更新を示しています)。
  2. ユーザーのオントロジーを保存します。
  3. テーブル登録を更新します。

📚 推薦文献(約10分読み)

元データセットの変更、特に以前に書き戻しプロセスを通じて編集を受けた行に対する変更については、さらに探求することができます。詳しくは、破壊的な変更について記載された Potential breaking changes in Edit object type をご覧ください。