exists 規則

exists 要求另一張可到達的表至少有一列符合條件。它適合表達「出貨前必須有有效訂單」或「費用申請必須有對應預算」等一跳式參照完整性。

Payload

{
  "type": "exists",
  "name": "客戶必須有已啟用合約",
  "table_id": "33333333-3333-4333-8333-333333333333",
  "match": {
    "客戶": "客戶"
  },
  "where": [
    { "column": "狀態", "op": "eq", "value": "已啟用" },
    { "column": "業務區域", "op": "eq", "value": "$row.業務區域" }
  ],
  "when": [
    { "column": "狀態", "op": "eq", "value": "準備出貨" }
  ]
}

table_id 是同 scope 或合法較廣 scope 的目標表。match 有一至兩組「目標表 link 欄位 → 本表 link 欄位」；兩側 link 必須指向同一目標。顯示名稱相同時，可把 value 寫成 "$same"。

where 在目標表的 stored scalar 上追加 filter，也可以指向目標表的系統 id 欄位（只接受不透明識別碼運算子——eq、neq、in、is_null、is_not_null；其他運算子在撰寫時被拒絕）。Literal 必須符合目標欄位型別；$row.<本表欄位> 可引用目前列的可比較 scalar。

執行語意

只有在 when 成立後才查找目標列。若目前列用於 match 的 link 缺值，本規則豁免；需要強制 link 存在時，另加合適的必填或 policy 契約。查找只允許一跳，避免把規則變成不可預期的任意 join。

自 2026-07-28 版起，對目標表系統 id 欄位的 where 條件會對準真正的主鍵。在那之前這種條件被編譯到幽靈 uuid 上、無聲比對不到——用 id 把關的 exists／not_exists 規則從來沒有擋下過任何寫入。現在提到 id 的存量規則是活的：下一次寫入就開始強制執行，請重新檢視在條件失效期間上線的規則。（運算子白名單屬於上方的 payload 契約。）

用 rules.preview 找出既有資料的風險，再透過 rules.set 發布完整規則清單。