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

📖 タスクの概要

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

🔨 タスクの説明

ontology_flight_alerts_logic リポジトリ内の flight_alerts.py ファイルを開きます。
返り値のステートメントを更新して、rule_name 行も削除するようにします： return source_df.drop('rule_id', 'rule_name')
ベストプラクティスに従ってコードをプレビュー、コミット、ビルドします。
データセットのビルドが完了したら、出力された flight_alerts データセットを開き、Details タブの Syncs セクションに進みます。同期が「実行中」の状態である場合がありますが、完了すると失敗が報告されます。
赤い失敗ブロック内の History ボタンをクリックします。これにより、この同期の履歴が順序付けられたリストになります。
リストの一番上の失敗した同期項目をクリックします。同期の詳細が表示されます。これには、展開可能な Phonograph schema mismatch error メッセージが含まれています。
Details の横にある > をクリックしてエラーメッセージを展開します。エラーの最後の行に注目してください：

foundryColumnsInPhonographTableSchemaMissingFromFoundrySchema=[rule_name]

登録された Phonograph テーブルは、rule_name 行を期待していましたが（以前に同期されていたため）、元データセットでは見つかりませんでした。
OMA で ユーザーの フライトアラートオブジェクトタイプを開きます。
左側のパネルで Datasources メニュー項目をクリックし、Phonograph ブロックまでスクロールします。OMA でも失敗したインデックスの状態が表示されます（Failed sync リンクをクリックすると、先ほど見た Job Tracker アプリケーションのエラーに遷移します）。