| 12345678910111213141516171819202122232425262728293031323334353637383940414243 |
- -- 1.0.539.warnings.ops.sql — GLOBAL HYGIENE WARNINGS(只观测,不阻断)
- --
- -- ⚠️ 本文件【不是】verify。AutoVersionUpdate 不执行 .ops.sql,只执行 <version>.sql
- -- 与 <version>.verify.sql。这里放的是「本批 writer 管不到、但值得盯」的全库卫生项。
- -- 人工执行:mysql <conn> < 1.0.539.warnings.ops.sql
- --
- -- 为什么不放进 verify:runner 对 verify 的每个切片都要求返回 1,没有"告警"这一档。
- -- 把这两项写成 verify 断言,等于让本批为边界外 writer 的行为背书,一旦对方回归就
- -- 阻断本批迁移、拖垮后端启动 —— 那是错误的责任划分,不是更严格。
- --
- -- 两项都【不影响】Stage-3 身份桥,身份桥完全不经过它们:
- -- PO.purchase_request_no → PR.pr_no → PR.sales_order_entry_id → mdp_std_so.order_entry_id
- -- ── WARN_GLOBAL_RECEIPT_INVALID_TENANT ─────────────────────────────────────────────
- -- 写入者已定位:Plugins/Admin.NET.Plugin.AiDOP/MaterialWarehouse/PurchaseReceiptMdpSyncService.cs
- -- 批次前缀 S5_PUR_RCT_STD_,属 S5 模块边界(CLAUDE.md 第九节模块边界表)
- -- 本批只对该表加了 idx_std_rct_po,未接管其写入
- SELECT 'WARN_GLOBAL_RECEIPT_INVALID_TENANT' AS `WARNING_CODE`,
- 'mdp_std_purchase_receipt' AS `TABLE_NAME`,
- `tenant_id` AS `TENANT`,
- COUNT(*) AS `CNT`,
- MAX(`sync_batch_id`) AS `LAST_WRITER_BATCH`,
- MAX(`update_time`) AS `LAST_WRITE_AT`
- FROM `mdp_std_purchase_receipt`
- WHERE `tenant_id` IS NULL OR `tenant_id` <= 0
- GROUP BY `tenant_id`;
- -- ── WARN_GLOBAL_PO_LITERAL_NULL ────────────────────────────────────────────────────
- -- mdp_std_purchase_order.work_order 是本批之前就存在的列,本批只做过一次性归一。
- -- 实测:租户 838 的 S3_MDP_FULL 批次里,贴源层同批次、同 source_biz_key 的
- -- NULLIF(NULLIF(JSON_UNQUOTE(JSON_EXTRACT(raw_data,'$.WorkOrd')),'null'),'')
- -- 求值结果为 NULL,标准层却仍出现字面量 —— 该值不可能由当前标准层 INSERT 在该批次
- -- 产生,写入者尚未定位。登记为 KNOWN ISSUE,不在本批处理。
- -- 该列【不作 Stage-3 归因】,归因走 purchase_request_no。
- SELECT 'WARN_GLOBAL_PO_LITERAL_NULL' AS `WARNING_CODE`,
- 'mdp_std_purchase_order' AS `TABLE_NAME`,
- `tenant_id` AS `TENANT`,
- COUNT(*) AS `CNT`,
- MAX(`sync_batch_id`) AS `LAST_WRITER_BATCH`,
- MAX(`update_time`) AS `LAST_WRITE_AT`
- FROM `mdp_std_purchase_order`
- WHERE `work_order` IN ('null', '')
- GROUP BY `tenant_id`;
|