pythia-impact

変更前に影響範囲を確認する

最初に宣言します：「まず pythia-impact を使って影響範囲を測定します。」

フェーズ： 調査 — 最初の Ask ゲートでもあります。影響範囲が広い場合は、コードを書く前に開発者へ伝えます。

Oracle オブジェクトを変更すると、それに依存するすべてのオブジェクトが再コンパイルまたは無効化されます。共有データベースのすべてのユーザーに対して、スキーマ全体で直ちに発生します。事前に把握するために必要なのは、コマンドをひとつ実行するだけです。

鉄則

NO CHANGE PROPOSED WITHOUT ITS IMPACT MEASURED FIRST

ワークフロー

1. pythia impact <OBJECT> --depth 2 — 依存するすべてのオブジェクトをツリー形式で表示します。最後に、重要な行が表示されます。 -- impact: N dependent objects, M currently VALID
2. pythia deps <OBJECT> --depth 2 — 逆方向、つまりそのオブジェクトが使用するものを表示します。変更が呼び出しやテーブルアクセスに関わる場合は、これを確認します。
3. pythia invalid — ベースラインを確認します。変更前から INVALID のものは、後で変更のせいにしてはいけません。apply は自動的に比較しますが、開始時の状態も把握しておきましょう。

数値の読み方

結果	対応
依存オブジェクトが 0 個	その旨を伝えて作業を進めます。それでも apply の後に確認してください。
依存オブジェクトが 1～9 個	提案とあわせて開発者に一覧を伝えます。
依存オブジェクトが 10 個以上、またはスキーマをまたぐ依存オブジェクトがある	ツリーを提示し、コードを書く前に明示的な許可を得ます。
依存オブジェクトがすでに INVALID	該当するものを指摘します。その領域はすでに不安定です。

テーブルにもコードと同じ対応が必要です。テーブルに対する impact を実行すると、ALTER によって無効化されるすべてのプログラムが表示されます。

危険信号 — 次のように考えていることに気づいたら作業を止めてください

考え	実際のところ
「ちょっとしたヘルパーにすぎない」	ヘルパーは、最も多くのオブジェクトから依存されているものです。
「コードを書いてから impact を確認しよう」	それでは、確認結果を設計に反映できません。手遅れです。
「apply のプレビューにも impact が表示される」	その行は、すでに把握している数値の確認であり、発見ではありません。
「新しいオブジェクトだから、依存するものはない」	そのとおりなら、思い込みではなく、根拠となる impact の出力とともにそう伝えます。

引き継ぎ

影響範囲を把握し、許容できることを確認したら、pythia-write でコードベースの規約に従って変更を書き、続いて pythia-apply でプレビューと検証を行って反映します。