概要
RETURNING 付き CTE を含むクエリを、ZTD の考え方でどのように扱うかを整理したい。
ここで重要なのは、ZTD は中間状態を直接テストするものではなく、最終端にあるクエリの観測可能な結果を検証するものである、という前提である。
そのため、RETURNING 付き CTE を含んでいても、最終的に観測対象が明確なクエリへ収束していれば、ZTD へ移植可能であるはずである。
背景
RETURNING 付き CTE は中間 relation を作るため、一見すると ZTD と相性が悪そうに見える。しかし、ZTD が検証するのは中間そのものではなく、最終的な query contract である。
したがって問題は "中間があること" ではなく、以下をどのように定義するかである。
- 最終的に何を query result とみなすか
- 副作用を伴うステップをどこまで許容するか
- ZTD の観測対象を final query result に限定したまま扱えるか
この整理がないまま実装を進めると、解析可能だが ZTD では扱えないケースと、扱えるケースの境界が曖昧になる。
論点
RETURNING 付き CTE を含んでいても、最終 SELECT または最終観測結果が明確なら ZTD 化可能とみなせるか- 中間 CTE は観測対象ではなく、最終 query contract の構成要素としてのみ扱うべきか
- pipeline 化された実行形態でも、最終端の query result だけを検証対象とする整理で十分か
- unsupported case をどこで fail-fast するべきか
受け入れ条件
RETURNING 付き CTE を含むクエリのうち、ZTD 適用可能な条件を明文化できる- "最終端の query result を検証する" という原則と矛盾しない形で説明できる
- ZTD 適用可能例と非対応例を最低限提示できる
- 必要であれば
queryspec / entryspec / 実行 contract 側の制約を整理できる
非ゴール
- 中間 CTE の内部状態そのものを ZTD の直接検証対象にすること
- すべての multi-step SQL を無条件で ZTD 対応にすること
概要
RETURNING付き CTE を含むクエリを、ZTD の考え方でどのように扱うかを整理したい。ここで重要なのは、ZTD は中間状態を直接テストするものではなく、最終端にあるクエリの観測可能な結果を検証するものである、という前提である。
そのため、
RETURNING付き CTE を含んでいても、最終的に観測対象が明確なクエリへ収束していれば、ZTD へ移植可能であるはずである。背景
RETURNING付き CTE は中間 relation を作るため、一見すると ZTD と相性が悪そうに見える。しかし、ZTD が検証するのは中間そのものではなく、最終的な query contract である。したがって問題は "中間があること" ではなく、以下をどのように定義するかである。
この整理がないまま実装を進めると、解析可能だが ZTD では扱えないケースと、扱えるケースの境界が曖昧になる。
論点
RETURNING付き CTE を含んでいても、最終SELECTまたは最終観測結果が明確なら ZTD 化可能とみなせるか受け入れ条件
RETURNING付き CTE を含むクエリのうち、ZTD 適用可能な条件を明文化できるqueryspec/entryspec/ 実行 contract 側の制約を整理できる非ゴール