8. [Repositories] Ontology Data Pipelines32 - 元データセットの破壊的な変更:パート 2
Warning

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

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

この内容は learn.palantir.com ↗ でもご覧いただけますが、アクセシビリティの観点から、ここに掲載しています。

📖 タスクの概要

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

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

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

🔨 タスクの説明

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

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

ここでは例を挙げて説明しませんが、破壊的な変更が元データセットの行のタイプの変更(例:timestampからdateへ)の場合、プロセスは少し異なります。その場合、次のようにします:

  1. そのプロパティの ベースフォーマットプロパティ メニューから更新します(下の画像は date タイプへの更新を示しています)。
  2. ユーザーのオントロジーを保存します。
  3. ユーザーのテーブル登録を更新します。

📚 推薦文献(読むのに約10分)

元データセットの変更、特に以前に議論した書き戻しプロセスを通じて編集を受けた行に関しては、さらに探求する余地があります。詳細を学ぶには、オブジェクトタイプの編集における潜在的な破壊的変更をご覧ください。