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

📖 タスクの概要

元データセットの変更が既にPhonographテーブルに登録され、インデックスされた列のスキーマを変更する場合、それは「破壊的」です。デフォルトでは、Phonographはスキーマの変更を自動的に受け入れないため、プロパティマッピングとPhonographテーブルの登録を手動で更新して処理する必要があります。このタスクでは、元データセット内の列の削除や型の変更（たとえば、doubleからintegerへの変更）を処理する方法を学びます。 予期せず、または予期していても、上流のデータソースでフライトアラートデータセットの一部であるrule_nameプロパティが削除されたと仮定します。まず、この削除をユーザーの元データセットでシミュレートし、次のタスクでその後の失敗に対処します。

🔨 タスクの説明

1. ontology_flight_alerts_logicリポジトリのflight_alerts.pyファイルを開きます。

2. returnステートメントを更新して、rule_name列も削除するようにします: return source_df.drop('rule_id', 'rule_name')

3. ベストプラクティスを使用してコードをプレビュー、コミット、ビルドします。

4. データセットのビルドが完了したら、出力されたflight_alertsデータセットを開き、DetailsタブのSyncsセクションに進みます。同期はまだ「実行中」の状態かもしれませんが、完了すると失敗が報告されます。

5. 赤い失敗ブロックのHistoryボタンをクリックします。これにより、この同期の履歴の順序付きリストに移動します。

6. リストのトップにある失敗した同期項目をクリックします。これで、同期の詳細が表示され、展開可能なPhonograph schema mismatch errorメッセージが含まれます。

7. Detailsという単語の横にある>をクリックしてエラーメッセージを展開します。エラーメッセージの最後の行に注目してください:

   foundryColumnsInPhonographTableSchemaMissingFromFoundrySchema=[rule_name]

   登録されたPhonographテーブルはrule_name列を期待していました（以前に同期されていたため）が、元データセットには見つかりませんでした。

8. OMAでユーザーのフライトアラートオブジェクトタイプを開きます。

9. 左側のパネルでDatasourcesメニュー項目をクリックし、Phonographブロックまでスクロールします。ここでもOMAで失敗したインデックスステータスを確認できます（Failed syncリンクをクリックすると、以前に見たJob Trackerアプリケーションのエラーに移動します）。