處理 DDL 與綱要發展

預期序號

當表格定義變更並啟用 DDL 擷取時，串流可以先傳遞 DDL 記錄，然後更新物件描述資料與表格特定的 DML 綱要，再使用新定義的後續記錄。整個 WebSocket 訊息的確切批次處理和順序都是實行詳細資訊；用戶每次出現時都必須處理綱要或描述資料記錄。

• 依其 id 快取綱要，而非僅依表格名稱。

• 以 qual_table 快取物件中繼資料，並在較新的記錄到達時加以取代。

• 請勿假設在連線期間收到的綱要在連線期間仍然有效。

• 如果 DML 記錄的必要綱要不明，而且下游系統無法接受無綱要資料，則暫停或將它當作無效字母。

• 自動套用原則允許的相容變更；將不相容的變更遞送至受控制的移轉工作流程。

相容與不相容的變更

變更	一般消費者動作
新增可為空值的資料欄	接受新欄位，並以非同步或動態方式更新順流綱要。
新增非空值資料欄	套用記錄前先確認預設 / 回填行為。
刪除資料欄	停止寫入欄位；根據保留原則保留歷史順流資料。
重新命名資料欄	除非另有管理對應狀態，否則視為刪除加號。
變更 JSON 原始類型或來源精確度	請先驗證轉換、精確度及下游相容性，再繼續進行作業。
變更索引鍵資料欄	先重建閒置、合併及刪除邏輯，再消耗新索引鍵底下的記錄。

DDL 處理原則

• 記錄稽核日誌中的 DDL pos、物件識別、敘述句以及作業時戳。

• 除非明確核准並保護行為，否則請勿直接對下游系統執行未複查的來源 DDL。

• 使用大小足以容納組織 DDL 的 maxDDLTextSize，並在偵測到或可疑截斷時發出警示。

• 一段時間內同一個表格應有多個綱要版本。將綱要 ID 保留在存檔的事件。

綱要登錄整合

用戶可以將頻內 JSON 綱要記錄發布至企業綱要登錄。保留原始 id，將它與資料串流和部署建立關聯，以及版本變更，而不是覆寫歷史綱要定義。登錄會補充程式實際執行綱要；它不會取代檢查點或來源歷程檔復原。