From 7abe3fbcd7a56ec9b14f0eaf3b0c155513645cf8 Mon Sep 17 00:00:00 2001 From: windyboy Date: Tue, 8 Sep 2026 12:01:38 +0800 Subject: [PATCH] =?UTF-8?q?docs(flight-state):=20v2=20=E8=AE=BE=E8=AE=A1?= =?UTF-8?q?=E3=80=81=E8=AF=84=E5=AE=A1=E6=8A=A5=E5=91=8A=E4=B8=8E=E5=86=B3?= =?UTF-8?q?=E7=AD=96=E5=A4=8D=E6=A0=B8=E5=85=A5=E5=8F=A3=E8=90=BD=E5=BA=93?= =?UTF-8?q?=20(ACM2-29)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- docs/decision-flight-state.md | 6 + docs/flight-state-design-v2.md | 215 +++++++++++++ docs/review-flight-state-2026-09-08.md | 405 +++++++++++++++++++++++++ 3 files changed, 626 insertions(+) create mode 100644 docs/flight-state-design-v2.md create mode 100644 docs/review-flight-state-2026-09-08.md diff --git a/docs/decision-flight-state.md b/docs/decision-flight-state.md index abdda92..f98e6df 100644 --- a/docs/decision-flight-state.md +++ b/docs/decision-flight-state.md @@ -4,6 +4,12 @@ > 本文正式确立选项 C 为最终方案：运营航班权威 `FLIGHT_SCHD` 与代版本 `SCHD_GEN` 提前至阶段 A 落自有 PostgreSQL；Redis 彻底退出动态权威与写路径。 > 交叉引用：[architecture.md](architecture.md)、[design.md](design.md)、[user-stories.md](user-stories.md)、ACM2-10（FS1–FS8 实施批次）。 +> **2026-09-08 复核入口**：详细证据与重构提案见 [运营航班状态设计评审](review-flight-state-2026-09-08.md)。 +> 本轮确认的部署边界：现场提供 Oracle 时使用 Oracle 11g，否则自行部署 PostgreSQL。 +> 评审保留单库原子提交方向，但发现 §9 固定资源槽位与本仓库三登机门样例冲突， +> 并指出集合往返、迁移与快照 CAS 的风险。下文保留历史定案记录；新提案尚未实装， +> 不应将历史“全部交付/保真”措辞视为双数据库生产验收证据。 + ## 1. 问题 阶段 A 航班动态权威 = Redis（`flightInfo` hash + `SCHD_GEN`），永续驻留、不落任何关系表 diff --git a/docs/flight-state-design-v2.md b/docs/flight-state-design-v2.md new file mode 100644 index 0000000..1011a09 --- /dev/null +++ b/docs/flight-state-design-v2.md @@ -0,0 +1,215 @@ +# 运营航班状态数据库设计 v2 + +状态：提案，待 ACM2-29 评审确认 +日期：2026-09-08 +适用部署：现场提供数据库时使用 Oracle 11g；现场不提供时使用自建 PostgreSQL。 + +## 1. 目标和边界 + +本设计为 msgexchange-v2 提供一个可恢复、可查询、可审计的运营航班当前状态库。系统接收共享 MySQL 信箱中的 SIS 报文，解析后在自有数据库中形成当前航班状态，并通过 outbox 投递 Kafka 和出站信箱。 + +本系统不是 AODB 主数据编辑系统，不负责票务、旅客、机队维护或资源排班优化。上游 AODB/CIIMS 仍是业务报文来源；本系统的“权威”仅表示本系统已成功处理的当前状态和待发送事件。 + +设计目标： + +- 航班主表、资源明细、快照版本、处理终态和 outbox 在一个本地事务中提交。 +- 保留 SIS 重复元素的顺序、源序号、资源号和全部属性，不因页面列数或现场样例缩减数据。 +- 明确区分“字段未出现”“设置值”“显式清除”“集合替换”。 +- 同一业务模型支持 PostgreSQL 和 Oracle 11g，数据库方言只存在于基础设施适配层。 +- 在迁移、重放、回填失败和进程崩溃后，可以判断哪些业务已经提交，避免重复应用。 + +## 2. 核心不变量 + +1. `FLIGHT_SCHD` 是当前航班状态的唯一写入目标；Redis 不参与动态状态权威。 +2. 只有主泵写入航班状态和快照成员。跨实例保护使用 `PIPELINE_LOCK` 行锁，但生产仍只允许一个活动实例。 +3. 一条消息的航班变更、明细变更、快照版本、outbox 事件和 `PROC_STATE=SUCCEEDED` 同事务提交；任一写入失败全部回滚。 +4. 快照差删只删除上一代在同一 `FDAY` 域内的成员；`ADFT` 和已经迁移到其他日期的航班不能被误删。 +5. 消息重放不得重复推进版本、重复生成业务事件或重复改变当前态。 +6. 合法的重复输入不得静默丢弃。容量不足、未知属性、非法结构必须显式失败并记录原因。 +7. 共享 MySQL 的成功回填属于提交后的补偿任务；回填失败不能把已成功的业务事务重新标记为失败。 + +## 3. 逻辑模型 + +```mermaid +erDiagram + FLIGHT_SCHD ||--o{ FLIGHT_GATE : has + FLIGHT_SCHD ||--o{ FLIGHT_CHECKIN : has + FLIGHT_SCHD ||--o{ FLIGHT_BELT : has + FLIGHT_SCHD ||--o{ FLIGHT_STAND_PLAN : has + FLIGHT_SCHD ||--o{ FLIGHT_CHUTE : has + FLIGHT_SCHD ||--o{ FLIGHT_DELAY : has + FLIGHT_SCHD ||--o{ FLIGHT_BRIDGE_OP : records + FLIGHT_SCHD ||--o{ FLIGHT_CHOCK_OP : records + FLIGHT_SCHD ||--o{ FLIGHT_ROUTE_POINT : has + SCHD_GEN ||--o{ SCHD_GEN_FLID : contains +``` + +### 3.1 航班主表：`FLIGHT_SCHD` + +一行代表一个 `FLID` 的当前状态。保留现有 SIS 标量字段和派生字段，但不再把重复资源展开为 `GATE1/GATE2` 这类固定槽位。 + +建议补充： + +| 字段 | 含义 | +|---|---| +| `FLID` | 本地航班主键；单机场单 AODB 部署下可继续使用。 | +| `FDAY` | DNLD 快照归属日，可为空；不等同于航班业务日期。 | +| `LAST_MESSAGE_ID` | 最后影响该航班的消息 ID，用于审计和恢复判断。 | +| `STATE_VERSION` | 有效状态变更版本；无副作用重放不得推进。 | +| `SODT_RAW` 等 | 上游原始字符串，保证兼容和对拍。 | +| `SCHEDULED_AT` 等 | 按机场业务时区解析后的查询字段。 | +| `CREATED_AT`、`UPDATED_AT` | 本系统写入时间。 | + +时间解析必须保留原值。SIS 使用本地机场时间格式时，不能直接当作 UTC；机场时区来自配置，解析失败不能静默转换。 + +### 3.2 重复资源表 + +每个明细表至少保留以下通用字段： + +```text +FLID 主表外键 +ORDINAL 本次集合中的输入顺序 +SOURCE_SEQ 源报文序号，如 GTNO/CKNO/ASNO/CSNO +RECORD_VERSION 产生该记录的状态版本 +CREATED_AT +UPDATED_AT +``` + +业务字段按 SIS 原样保存。例如： + +| 表 | 主要字段 | +|---|---| +| `FLIGHT_GATE` | `GATE`、`PGOT`、`PGCT`、`GOTM`、`GCTM`、`GTYP` | +| `FLIGHT_CHECKIN` | `CHKC`、`CCLS`、`PCOT`、`PCCT`、`COTM`、`CCTM`、`CTYP` | +| `FLIGHT_BELT` | `BELT`、`BCLS`、`PCOT`、`PCCT`、`FBAG`、`LBAG`、`BTYP` | +| `FLIGHT_STAND_PLAN` | `PSST`、`STST`、`STET` | +| `FLIGHT_CHUTE` | `CHUT`、等级、计划/实际时刻、类型字段 | +| `FLIGHT_DELAY` | `CODE`、`STRT`、`DURA`、原文说明 | +| `FLIGHT_BRIDGE_OP` | `ASNO`、`ABDG`、`ABOP`、`AOTM` | +| `FLIGHT_CHOCK_OP` | `CSNO`、`CHID`、`CHST`、`CHTM` | +| `FLIGHT_ROUTE_POINT` | `ROUTE_KIND`、`RTNO`、`APCD`、`SCAT`、`SCDT` | + +主键推荐为 `(FLID, ORDINAL)`。`SOURCE_SEQ` 是源数据，不默认唯一；相同资源号不代表同一条分配记录，因此不能按 `GATE`、`CHKC` 或 `ABDG` 全局去重。 + +`FDIV`、`FRET`、`FLAB` 当前是 XSD 中的单值结构，可以保留在主表的明确前缀列中；必须定义显式清除语义。`SRVT`、`VIPF`、`MAFL` 如暂时不需要 SQL 查询，可使用专用集合载荷表保存原始文本；Oracle 11g 使用 `CLOB`，PostgreSQL 使用 `TEXT`，应用层负责结构校验。 + +### 3.3 快照版本 + +```text +SCHD_GEN + FDAY 主键 + VERSION 单调递增版本 + LAST_MESSAGE_ID 生成该版本的消息 + CONTENT_DIGEST 可选，内容摘要 + UPDATED_AT + +SCHD_GEN_FLID + FDAY + FLID + PRIMARY KEY (FDAY, FLID) +``` + +`VERSION` 只是顺序令牌；重放判断必须结合 `LAST_MESSAGE_ID` 或明确的快照身份，不能只比较 `VERSION == expected + 1`。 + +### 3.4 处理和投递表 + +保留 `PROC_STATE`、`MSG_EVENT`、`PUMP_JOB`、`REQ_TRACK` 等现有管道表。建议在 `MSG_EVENT` 中记录 `CMINMSGS_ID`、`STATE_VERSION` 和 `IDEMPOTENCY_KEY`，便于确认同一业务事件是否已经入队。 + +## 4. 消息写入语义 + +解码层把 XML 转换为显式命令，仓储层不再猜测字符串含义： + +```text +Unchanged 报文没有该字段，不修改数据库 +Set(value) 写入或覆盖值 +Clear 按协议删除该值 +Replace(list) 用完整集合替换旧集合 +Apply(item, key) 按协议中的源序号更新单条记录 +``` + +通用规则： + +- 外层标量字段默认是字段级增量合并：未出现不修改，出现则覆盖。 +- DNLD 对航班集合使用完整快照替换；集合缺失表示“按 DNLD 规则处理”，不能自动推广为清空所有旧资源。 +- 集合出现且被协议定义为快照时，在同一事务中删除该航班该集合的旧明细，再批量写入新明细。 +- `GTNO=0`、`CKNO=0` 等清除标记只对协议明确规定的集合生效。 +- 非法 JSON、未知字段、超长文本和超过协议容量的输入不得截断后成功。 + +成功提交后的出站载荷必须从同一份 `nextState` 生成，不能让仓储先丢字段、事件再使用原始输入。 + +## 5. 事务流程 + +```text +解析并校验报文（锁外） + ↓ +取得 PIPELINE_LOCK 行锁 + ↓ +复核消息状态和快照身份 + ↓ +读取当前航班与 SCHD_GEN + ↓ +计算 nextState + ↓ +写主表、明细表、快照成员和版本 + ↓ +从 nextState 生成 MSG_EVENT + ↓ +PROC_STATE = SUCCEEDED + ↓ +提交 + ↓ +补偿回填共享 MySQL / 投递下游 +``` + +CAS 失败直接回滚并进入可重试的 `FAILED(INFRA)`；不能用相同版本号推断“已经是我的提交”。 + +提交之后的回填失败只创建或更新补偿记录。重启时先检查 `PROC_STATE` 和 outbox，已经成功的消息不能重新执行航班业务变更。 + +## 6. PostgreSQL 与 Oracle 11g + +两种数据库使用相同的仓储接口、领域模型和测试样例，分开提供迁移和 SQL 实现。 + +| 能力 | PostgreSQL | Oracle 11g | +|---|---|---| +| Upsert | `INSERT ... ON CONFLICT` | `MERGE` 或受控的 UPDATE/INSERT | +| 长文本 | `TEXT` | `CLOB` | +| 时间 | `TIMESTAMPTZ` | `TIMESTAMP` 配合明确时区转换策略 | +| 自增 ID | identity/sequence | sequence | +| 锁 | `SELECT ... FOR UPDATE` | `SELECT ... FOR UPDATE` | +| 迁移 | PG 专用 Flyway location | Oracle 11g 专用 Flyway location，经目标版本实测 | + +Oracle 11g 的 `VARCHAR2` 受 4000 字节限制，空字符串按 `NULL` 处理。因此应用命令必须保留 presence/operation 信息，不能把“缺失、空串、NULL、清除”当作同一个状态。JDK 25、Oracle 11.2 补丁、JDBC 驱动、Flyway 和连接池的组合必须在现场环境实测，不能用 PostgreSQL 通过代替 Oracle 验收。 + +## 7. 迁移和发布 + +1. 先增加明细表和主表追踪字段，不删除现有集合列。 +2. 从旧列、完整 DNLD 或可信历史输入回填明细表。 +3. 逐航班比较数量、顺序、源序号、属性、空值和出站载荷。 +4. 切换读路径和写路径到无损模型，保留旧结构一个回退窗口。 +5. 确认对拍、回放、备份恢复和查询性能通过后，再删除旧的损失性列和转换代码。 + +已经执行过直接删除旧集合列的实例无法从新槽位列推回第三个登机门、原始序号或多次操作；需要旧库备份、完整 DNLD 或原始报文恢复。 + +## 8. 验收标准 + +- 三个及以上登机门、非连续源序号、相同资源号不同属性都能完整读回。 +- 多次靠桥/撤桥、上/下轮挡和多条延误记录不丢失顺序或资源身份。 +- 未出现、显式清空、集合替换、序号删除四种语义有独立测试。 +- 主表、明细、`SCHD_GEN`、outbox 和成功终态原子提交；任意一步失败全部回滚。 +- 同一快照重放不增加版本和事件；不同快照争用同一版本时只能一个成功。 +- 共享信箱回填失败不会重新执行业务状态变更。 +- PostgreSQL 与 Oracle 11g 各自通过新建库、升级库、回滚和并发锁测试。 +- 查询视图可以提供首个/第二个资源和总数，但完整明细仍可查询。 +- 对拍工具按字段、顺序、空值和集合内容比较，不通过忽略差异来“洗绿”。 + +## 9. 实施顺序 + +| 阶段 | 内容 | +|---|---| +| P0 | 修复快照 CAS、提交后回填状态边界，建立 16 类结构的语义矩阵。 | +| P1 | 建立无损明细表、领域命令和 nextState 生成；完成 DNLD 与一个 FLOP 纵向链路。 | +| P2 | 完成旧数据回填、双读对拍和兼容查询视图。 | +| P3 | 分别完成 PostgreSQL 和 Oracle 11g 的 DDL/DML、迁移和集成测试。 | +| P4 | 根据真实查询计划增加索引，确认回退窗口关闭后删除旧损失性结构。 | + +本设计对应 ACM2-29 的后续实现；在评审确认前，不应将当前 V1.2.0 固定槽位结构作为生产保真方案。 diff --git a/docs/review-flight-state-2026-09-08.md b/docs/review-flight-state-2026-09-08.md new file mode 100644 index 0000000..57faa07 --- /dev/null +++ b/docs/review-flight-state-2026-09-08.md @@ -0,0 +1,405 @@ +# 运营航班状态设计评审与重构建议 + +评审日期：2026-09-08。代码基线：`cd5de56`。评审对象：[decision-flight-state.md](decision-flight-state.md)、相关 SQL、仓储、快照流程、消息处理和测试。 + +本文件是有证据的设计评审和可实施提案，**不代表下述重构已经实装，也不自动取代 ACM2-28/29 的历史决策**。本次只新增评审文档及原决策文档的评审入口，没有修改生产代码、执行数据库迁移或更新 Plane 状态。 + +## 1. 结论与部署边界 + +**保留“自有关系数据库内原子提交航班状态、处理终态和 outbox”的架构；建议撤销“全宽表、零子表、超界丢弃”的硬性限制，改为航班标量主表、无损重复明细、按需展示视图。** + +两项决策必须分开：选择一个事务内的权威存储，解决的是一致性；如何存放重复资源，解决的是信息保真和查询模型。前者正确，不足以证明后者正确。 + +本轮用户已明确：**现场提供 Oracle 时一定是 Oracle 11g；否则自行安装 PostgreSQL。** 因此实际产品边界是两种互斥部署配置，不能继续把 Oracle 当作遥远的假设，也不应让一个部署同时把 PG 和 Oracle 都作为动态状态权威。共享 MySQL 信箱边界保持原样。 + +评审建议分为三个层次： + +1. 立即修正会丢数据或破坏事务不变量的实现与验收口径。 +2. 用最小的领域结构承载 SIS 已有数据，完成一个 DNLD→资源增量→查询/通知的纵向闭环。 +3. 分别验收 Oracle 11g 和 PostgreSQL 适配；完整 AODB、资源优化调度、票务和历史分析不纳入本次重构。 + +## 2. 当前决策的合理部分与证据不足部分 + +| 原设计 | 评审结论 | 理由 | +|---|---|---| +| 航班状态迁回自有库，与 `PROC_STATE`、`MSG_EVENT` 同事务 | 保留 | 消除原 Redis 状态与 PG 终态之间的跨存储提交窗口。 | +| Redis 退出状态权威 | 保留 | 本项目已依赖自有关系数据库，增加另一个状态权威不带来必要收益。 | +| Handler 纯函数，基础设施通过仓储隔离 | 保留 | 可以独立验证 KEEP/FIX 业务规则；物理表不应决定 Handler 的业务表达能力。 | +| 增量按字段合并，DNLD 全量替换 | 保留总体方向 | 需进一步区别字段未出现、显式清空、集合全量、操作记录增量。 | +| `FDAY` 域化差删、ADFT 不随旧代误删 | 保留 | `FDAY` 是快照所有权，不应冒充航班运营日期。 | +| `PIPELINE_LOCK` 行锁 | 有条件保留 | 是写事务互斥工具，还不是完整的双实例 FIFO 或主备协议。 | +| 全字段字符串保持 legacy 兼容 | 保留原始值，补类型化查询面 | 时间字符串不适合排序/范围查询；Oracle 空串语义也会影响保真。 | +| 固定 2/3/2/2/2 槽位，超界丢弃 | 否决作为权威表示 | 项目自带三登机门样例已能触发丢失，不只是 XSD 理论边界。 | +| 多次操作只留一次、按资源号去重 | 否决作为通用规则 | 分配记录与物理资源不是同一实体；操作序号和资源身份有业务含义。 | +| 零 CLOB、零子表、零方言成本 | 撤销硬性约束 | Oracle 11g 支持关系明细和 CLOB；串行事务与多表原子写入并不冲突。 | +| “重启即恢复，RPO=0” | 限定故障模型 | 本地事务关闭双写窗口，不等于数据库介质损坏、异步副本切换也零丢失。需单独定义备份、恢复与提交持久性要求。 | +| “单行 upsert 亚毫秒，无新增往返” | 改为待测目标 | 本轮未见支撑数据。当前增量路径实际包含父行 upsert 和字段 UPDATE，快照还涉及批量、差删、版本、事件。 | + +文档也有演进失配：`decision-flight-state.md` §6/8/9 分别保留 JSONB、集合文本、固定槽位三个阶段，`design.md` §2 仍描述集合序列化文本；`architecture.md` 同时有行锁互斥与运行期排他尚未完成的说明。应为“当前有效规则”和“历史被替代规则”设置明确索引。 + +## 3. 互联网方案：哪些可以借鉴，哪些不能照搬 + +本次使用 TinyFish 搜索并读取一手资料。连接器未提供 `batch_create`，因此资料逐个 URL 读取，未使用异步浏览自动化。没有获得商业 AODB 的生产物理 DDL；不能把产品介绍或信息交换标准描述为厂商数据库表结构。 + +| 来源与性质 | 已核实内容 | 对本项目的适用性与限制 | +|---|---|---| +| IATA《AIDX Implementation Guide》v3.0，2014，基于 14.1 schema；行业信息模型 | 航段是核心结构；重复元素保留顺序；文档包括资源、共享航班、运行时刻和不正常运行身份。 | 用于检验模型是否丢失领域信息。它不是本项目 SIS 的替代协议，也不是最新版本认证。 | +| EUROCONTROL A-CDM Specification，2025-01-30；运行流程模型 | 将进港与出港关联，通过里程碑推进周转和离港估计。 | 支持把进出港记录、周转关系和操作时刻分清；不要求本项目实现完整 A-CDM。 | +| SITA Airport Management；商业产品功能边界 | 区分航班管理、固定资源、移动资源、协同决策，并涉及多机场。 | 可借鉴职责分离；公开页不披露其物理表，不能推断“它采用某种子表”。 | +| Postgres Professional Airlines 演示库，版本 10 文档；公开关系 schema | `flights` 有独立 `flight_id`、计划/实际时刻和机场引用；通过 `flights_v` 提供附加展示信息。 | 是能阅读字段、键和约束的数据库示例，但侧重订票，不是机场生产 AODB。 | +| Oracle Database 11g SQL Reference；平台约束 | SQL `VARCHAR2` 有 4000 字节上限；字符长度为零按 NULL 处理。 | 必须影响长度、空值、测试和驱动适配，不能仅替换 upsert 语法。 | + +来源：[IATA AIDX 指南](https://www.iata.org/contentassets/2db667ac37c045dbbb537eeb446dd9b2/aidx-xml-implementation-guide.pdf)、[EUROCONTROL 2025 A-CDM](https://www.eurocontrol.int/publication/eurocontrol-specification-airport-collaborative-decision-making-cdm)、[SITA Airport Management](https://www.sita.aero/solutions/sita-at-airports/sita-operations-at-airports/sita-airport-management/)、[Postgres Professional schema](https://postgrespro.com/docs/enterprise/10/apjs04.html)、[Oracle 11g 数据类型](https://docs.oracle.com/cd/E11882_01/server.112/e41084/sql_elements001.htm)、[Oracle 11g NULL](https://docs.oracle.com/cd/E11882_01/server.112/e41084/sql_elements005.htm)。 + +具体可借鉴之处： + +- AIDX §3.1.9 要求重复数据保持可追踪的顺序，更新一个重复元素时携带其余元素；附录 H 中登机门可重复三次、值机可表达不同类型和不连续范围、延误原因可有多项。这足以反驳“两登机门、一延误是通用航空事实”，但本项目每个消息类型的最终行为仍应以 SIS 和现场协议为准。[IATA 指南](https://www.iata.org/contentassets/2db667ac37c045dbbb537eeb446dd9b2/aidx-xml-implementation-guide.pdf) +- 进港和出港关联有运营价值，但不应因为是同一架飞机就合成同一条记录；周转关系应显式表达，不能从航班号或机尾号临时猜测。[EUROCONTROL A-CDM](https://www.eurocontrol.int/publication/eurocontrol-specification-airport-collaborative-decision-making-cdm) +- 展示可以是视图，权威表不必复制屏幕布局。演示库的 `flights_v` 提供本地时刻及机场附加信息，展示了这种分离方式；其票务实体和简化自然键不应直接搬入 SIS 中间件。[Postgres Professional schema](https://postgrespro.com/docs/enterprise/10/apjs04.html) + +以下表设计是结合这些资料和项目代码得出的**本次建议**，不是宣称行业标准强制规定了这些表名或范式。 + +## 4. 关键发现：契约保真 + +### F1 — 高：当前两个登机门槽位直接违反本仓库样例 + +证据： + +- [SIS §3.34.3](legacy/SIS_AODB_RMS-V0.1.md#sec-3-34-3)，源文件约 8321–8340 行，同时给出 `GTNO=1/G28`、`GTNO=2/G33`、`GTNO=3/G23`。 +- `JdbcPgRepositories.kt:367` 定义 GTDT 两槽位；`:466` 的 `flattenSlots` 使用 `.take(c.slots.size)`。 +- `decision-flight-state.md` §9 却称已通过该规范样例核验，并允许超界丢弃。 + +当前转换实际把三条变成两条，G23 消失。对于合法输入，系统仍可能提交 `SUCCEEDED`，不会因丢失而自动重试。这是权威存储的损失性转换，不只是展示不全。 + +**建议**：完整保存记录，界面需要两列时仅在视图投影前两项，并显示总数/更多信息。仅把上限从 2 改成 3 不能解决其他集合及将来的合法输入。 + +### F2 — 高：资源编号、分配身份和数组位置被混为一谈 + +`flattenSlots` 并不按 `GTNO/CKNO` 选槽，而是按去重后的数组顺序赋槽；`slotView` 再用下标合成序号。因此只输入 `GTNO=3`，读回就是 `GTNO=1`。这也与文档“槽位号即报文序号属性”不符。 + +同一函数对五类集合都按资源号去重。两个 `CHKC=01`、`CCLS=F/Y` 的分配会丢掉后一条；机位不同时间段、相同资源不同属性也存在同类风险。没有证据证明这些是可无条件抹平的冗余。 + +**建议**：分别保存 `ordinal`（报文出现顺序）、`source_seq`（源序号字符串）和资源号；资源号本身不设“每航班唯一”的约束。是否允许重复源序号应由协议矩阵决定，不能由 SQL 唯一键替上游作决定。 + +### F3 — 高：操作历史被不充分地压缩为单一里程碑 + +- SIS 约 5127–5157 行明确 ABTM 按每次靠桥/离桥重复，`ASNO` 标识操作序号，`ABDG` 标识实际桥资源。 +- XSD `BRIDGEDATA`（约 1714 行）也包含 `ABDG/ABOP/AOTM/ASNO`。 +- `flattenAirbridge` 只取首个 A 和首个 D，读回时合成 1/2，完全不输出原条目的 `ABDG`。 +- `flattenChocks` 只保留首次 ON/OFF，丢掉 `CSNO/CHST`；`chocksView` 给两者都生成 `CSNO=1`。 +- `flattenDelay` 总取首条；XSD 的 DELY 为 `maxOccurs="unbounded"`（约 2251 行），不能从“一次只显示一条原因”推出只存一条。 + +**建议**：原始操作列表和“当前/首次/最近一次里程碑”分开。后者可以派生，但必须命名清楚，并定义按源序号、发生时刻还是到达顺序选择；现在的 `firstOrNull` 不具备“当前有效”的证明。 + +### F4 — 高：显式清空与缺失混用，异常对象处理又不一致 + +`FlightFields` 是 `Map`，通过键是否存在、字符串中嵌套 JSON 表达不同含义。当前存在： + +- GTDT 的 `[]`/`null` 会清空槽位，读回没有 GTDT 键；如果下游以“键缺失=保持旧值”消费，就不能代表清空。 +- `flattenExceptions` 对 `FRET="null"`、空对象、非对象或非法 JSON 返回，不写清空列；旧异常可能保留。 +- 异常缺失属性不清空，与文档“集合键出现即整体替换”的统称不一致。 +- 自由文本在 `REMC/RSN/value/#text` 中猜一个键，读侧固定输出另一个键，无法承诺原格式往返。 + +`FRET="null"` 不产生清空写入已由转换诊断复现。是否在每一种真实 XML 清除消息中触发，还需 Codec/Handler 的实际映射；不能把诊断输入误称为已经上线的报文路径。 + +**建议**：消息解释层显式使用 `Unchanged / Clear / Set` 和 `Unchanged / Clear / Replace / 按协议定义的操作`。编解码层负责将 XML 删除标记翻译成操作；仓储不要靠字符串内容猜业务命令。 + +### F5 — 高：出站载荷与数据库当前态可能在同一次提交后不同 + +`SnapshotFlow.kt:99` 从未压缩的 `normalized` 构造事件；仓储在写入时截断/去重。三门快照由此可能产生“Kafka 有三门，数据库点查只有两门”。普通路径也分别接受 `flightChanges` 和已序列化 `schdPush`，一致性依赖 Handler 自觉。 + +事务原子性保证两者一起提交，**不保证它们表达同一状态**。 + +**建议**：统一生成完整的 `nextState`，无损持久化和线格式序列化都使用它。增加 `readAfterWrite == nextState` 和 `wirePayload == wire(nextState)` 两道断言；不要只测试事件数量与事务提交。 + +## 5. 关键发现：迁移、并发与恢复 + +### F6 — 高：V1.2.0 不是有数据的安全升级迁移 + +[V1.2.0 SQL](../src/main/resources/db/migration/V1.2.0__flight_resources.sql) 第 97–104 行直接删除 16 个旧集合列，前面只有 ADD COLUMN，没有数据转换或回填。若 V1.1.0 数据库有集合值，升级后旧值丢失，新列仍为 NULL。 + +空库首次安装不会出现这个损失；本轮未访问现场，不能声称现场已发生丢失。但当前脚本不具备带数据升级能力。 + +**建议**：扩展表结构→回填→逐字段核验→切换读写→观察→最后删旧列。已应用的 Flyway 版本不要直接改写；尚未升级但会经过 V1.2.0 的实例，必须在它执行前做无损导出或另行制定受控升级路线。后续新增迁移无法凭空恢复已被删除的数据。 + +### F7 — 高：CAS 失败后版本相同，不能证明是同一个快照重放 + +`SnapshotFlow.kt:59` 在锁外读取 generation，`:69` 先覆盖数据，`:82–87` 在 CAS 失败时只要 `again.version == expected + 1` 就继续成功。 + +可由代码推导的交错： + +1. 处理者 A、B 在锁外都读到版本 5，但携带不同快照。 +2. A 拿锁，写入集合 A，把 generation 推到 6 并提交。 +3. B 随后拿锁，按旧预期写入集合 B 和旧差集。 +4. B 的 CAS 失败，看到版本恰为 6，于是继续提交事件和 SUCCEEDED。 +5. generation 成员仍可能是 A，航班内容却被 B 改写；这不是 no-op。 + +生产严格只有一个活动处理者时，此交错不会自然出现；它揭示的是文档宣称的交叉实例保护不能成立，也不能以“已有行锁”作为开放多实例的依据。本轮未做真实双连接复现。 + +现有 `FlightSchdInvariantTest:223` 的 mock 在 CAS 失败后仍返回版本 5，没有覆盖恰好为 6 的分支。 + +**建议**：锁内读 generation 和有效处理身份；CAS 失败统一回滚。若需要重放短路，必须在任何状态写入前，使用已成功的消息身份/明确的快照身份识别，同内容摘要只能作为补充，不能仅凭版本号。为 generation 增加 `last_snapshot_message_id`（或同等可核验身份）与可选摘要，保留版本只作为顺序令牌。 + +### F8 — 高（双实例场景）：行锁没有覆盖“读状态→决策” + +`Pump.kt` 在 `txManager.inTransaction` 之前读航班视图并调用 Handler。两实例可以基于同一旧状态分别计算，然后串行覆盖。`PIPELINE_LOCK` 也不自动保证较小信箱 ID 的处理者先取得锁。 + +**建议**：继续单活动实例部署。要增强防错，应在锁内复核处理终态与队头、读取当前态、应用纯决策并提交；XML 解析等不依赖当前态的工作可在锁外。切勿使用 `SKIP LOCKED` 跳过较小业务消息破坏严格 FIFO。数据库隔离级别也不能替代处理身份与顺序协议。 + +### F9 — 高（提交后异常）：回填失败可能落回处理失败路径 + +`Pump.kt:235` 的 `backfillOnSuccess` 位于状态事务提交之后；异常会被外层 `processOne` 归为 INFRA 并交给 `procFailure`。快照回填也处于提交后。若再次进入完整处理流程，有重复事件、重复快照推进或覆盖新状态的风险。 + +**建议**：成功终态不可被回填错误降回业务失败。单独持久化回填待办，失败只重试回填；业务重试入口复核数据库中已提交终态。恢复能力应围绕“事务提交前/后”和“外部投递前/后”分别测试。 + +## 6. Oracle 11g 兼容性：不是把 ON CONFLICT 换成 MERGE + +| 维度 | 当前风险 | 设计要求 | +|---|---|---| +| 空串 | PG 可保存空字符串，Oracle 字符零长度按 NULL；`Map` 的键存在性也会变化。 | 对有业务意义的空值保留 presence 标记或无损文档；不要未经协议认可全局将空串、NULL、缺失视为同义。[Oracle NULL](https://docs.oracle.com/cd/E11882_01/server.112/e41084/sql_elements005.htm) | +| 长度 | 现有 `*_TEXT VARCHAR(512/2000)` 是序列化后的整列表；XSD 不限条数的列表可合法超长。 | 明确 BYTE/CHAR 与数据库字符集；11g SQL VARCHAR2 仍受 4000 字节边界，使用子表或 CLOB 承接无界集合。[Oracle 数据类型](https://docs.oracle.com/cd/E11882_01/server.112/e41084/sql_elements001.htm) | +| 时间 | `SODT/ESTT/ACTT` 是源字符串；数据库审计时间使用另一套类型。 | 区分业务发生时刻、收到时刻、提交时刻；原值和标准化时间并存。 | +| DDL | PG 迁移含 `BIGSERIAL`、`TEXT`、`ADD COLUMN` 等，整个辅助管道也需适配。 | 分 PG/Oracle migration location；定义 NUMBER、序列、长文本、时间与约束的映射。 | +| DML | 不只有 upsert，还包括生成键、分页、锁、批量和查询日期处理。 | 方言留在适配层，业务层不按数据库类型分支。 | +| 事务 | 行锁概念可共用，连接绑定和失效恢复仍须实测。 | 明确同一事务同一数据源；`JdbcOps` 当前 ThreadLocal 未按数据源区分，未来多个自有连接源不得误复用。 | +| 运行组合 | 当前依赖有 PG 驱动与 PG Flyway 模块，没有可据此验收的 Oracle 组合。 | 在目标 11.2 补丁级别上验证 JDK 25、具体 JDBC 驱动、迁移工具和连接池组合。不能凭“ojdbc8”名称认定支持。 | + +11g 缺少现代 SQL/JSON 能力，不等于不能存储 JSON 文本。当前 V1.2.0 自己还把 SRVT/VIPF/MAFL 保存为 JSON 数组字符串；“废除 JSON 存储”因此也不是准确描述。真正需要选择的是：哪些字段要求 SQL 查询/约束，哪些原始结构只需无损保存。 + +超长 fail fast 优于静默截断，但如果合法消息仅因本地任意长度限制进入反复重试，严格 FIFO 会被持续阻塞，最终 DEAD 后仍缺失有效更新。容量问题应在投产前按契约和观测量解决；永久验证错误与暂态基础设施错误也应分开分类。 + +## 7. 建议的领域边界 + +本项目是外部 AODB 报文的有状态接收与分发系统。这里的“权威”指**本系统已处理消息所形成的当前态及下游输出**，不表示取得上游 AODB 的业务编辑权。 + +| 概念 | 建议定义 | 不要混用 | +|---|---|---| +| 航班记录 | 当前源系统用 FLID 标识的进/离港运营记录 | 航线模板、每天重复的航班号、航空器、旅客行程 | +| 航段/周转关系 | 对现有源关系作明确映射，需要时关联两个记录 | 不能先假定本地 FLID 与 AIDX 航段完全同义，也不能仅按机尾号自动配对 | +| 资源分配记录 | 某航班某一序号的门/柜台/转盘/计划机位等分配 | 资源主数据；相同资源号不一定是同一分配 | +| 操作记录 | 一次靠桥、撤桥、上/下轮挡等源记录 | 当前资源、首次/最近里程碑 | +| 运营日期 | 按明确机场时区及业务口径定义的日期 | `FDAY` 快照归属日；不要直接改现有主键 | +| 消息身份 | 源消息去重与处理恢复标识 | 快照版本、FLID、发生时刻 | +| 当前态、历史、展示 | 当前态由消息合并；历史单独留痕；展示可派生 | outbox 的合并通知不是完整运行事件历史 | + +现有单机场/单 AODB 数据域可继续以 FLID 作主键。双流/天府若以后汇入一个实例，先核实跨机场和跨源 FLID 唯一性；只有证实会冲突才引入 `(source_system, airport_scope, external_flid)` 唯一映射及内部 ID。当前没有证据证明已经发生碰撞，不把这个潜在需求扩大为立即全表换键。 + +## 8. 推荐关系模型 + +### 8.1 主表与明细的分工 + +```mermaid +erDiagram + FLIGHT_SCHD ||--o{ FLIGHT_GATE : contains + FLIGHT_SCHD ||--o{ FLIGHT_CHECKIN : contains + FLIGHT_SCHD ||--o{ FLIGHT_BELT : contains + FLIGHT_SCHD ||--o{ FLIGHT_BRIDGE_OP : records + FLIGHT_SCHD ||--o{ FLIGHT_CHOCK_OP : records + FLIGHT_SCHD ||--o{ FLIGHT_ROUTE_POINT : contains + SCHD_GEN ||--o{ SCHD_GEN_FLID : owns +``` + +图只列主要关系；计划机位、通道、延误的明细见下表。`SCHD_GEN_FLID` 是代成员历史元数据，不强行对当前航班加级联外键，避免清场或跨代迁移改变既有差删语义。 + +`FLIGHT_SCHD` 保留 FLID、FDAY、标量业务字段、created/updated 时间。新增字段按实际查询和恢复需求选择： + +- `LAST_MESSAGE_ID`：追踪最后影响该航班的消息，关联审计，不代替业务去重。 +- `STATE_VERSION`：需要一致查询或恢复校验时使用；每次有效变更推进，不因无副作用重放推进。 +- `SCHEDULED_AT` 等类型化时间：从原始 SODT 等派生，保留原值。 +- presence/解析状态：只在需区分空/缺失或解析失败的字段上引入，不滥加全表状态。 + +### 8.2 16 类结构的建议映射 + +| 现有集合 | 建议存储 | 必须保留的关键含义 | +|---|---|---| +| GTDT | `FLIGHT_GATE` | ordinal、GTNO、GATE、PGOT/PGCT/GOTM/GCTM、GTYP | +| CKDT | `FLIGHT_CHECKIN` | ordinal、CKNO、CHKC、CCLS、计划/实际开放关闭、CTYP；不按 CHKC 去重 | +| CLDT | `FLIGHT_BELT` | ordinal、CLNO、BELT、BCLS、计划时刻、首末行李时刻、BTYP | +| PSDT | `FLIGHT_STAND_PLAN` | ordinal、PSNO、PSST、开始/结束时刻 | +| CHDT | `FLIGHT_CHUTE` | ordinal、CHNO、CHUT、等级、计划/实际时刻、类型 | +| DELY | `FLIGHT_DELAY` | ordinal、CODE、STRT、DURA、原文说明；不以“唯一当前原因”覆盖列表 | +| ABTM | `FLIGHT_BRIDGE_OP` | ordinal、ASNO、ABDG、ABOP、AOTM | +| CHOT | `FLIGHT_CHOCK_OP` | ordinal、CSNO、CHST、CHID、CHTM | +| ROUT、ERUT | 共用 `FLIGHT_ROUTE_POINT`，区分 route_kind | ordinal、原 RTNO、APCD、SCAT、SCDT，避免自定义分隔符和重编号 | +| FDIV、FRET、FLAB | 主表前缀列可保留 | 单值符合 XSD；明确文本键、空值、清除规则即可，不必强拆子表 | +| SRVT、VIPF、MAFL | 第一阶段允许无损文本旁表；查询需求明确后再结构化 | JSON 数组原有顺序、全部属性和长度；Oracle 使用 CLOB，PG 使用 TEXT；应用验证结构 | + +低频集合旁表可定义为 `FLIGHT_COLLECTION(FLID, COLLECTION_KIND, PAYLOAD, SCHEMA_VERSION)`，主键是 `(FLID, COLLECTION_KIND)`。这不是用于任意核心字段的 EAV 表，只承接暂未需要 SQL 过滤的完整集合。MAFL 的共享航班关系一旦用于关联查询，应提升为明确关系，而不是在 SQL 中解析文本。 + +明细表数量由独立属性和读写语义决定，既不追求“零子表”，也不要求所有 16 类各建一张。1:N 表只存实际 N 行；支持 XSD 上限并不等于每航班预建 99 行。 + +### 8.3 单个明细表的可评审形状 + +以下是逻辑字段设计，非可直接运行的双数据库 DDL： + +```text +FLIGHT_GATE + FLID FK -> FLIGHT_SCHD + ORDINAL positive integer; input order + SOURCE_SEQ source GTNO string + GATE_CODE source GATE + PLANNED_OPEN_RAW source PGOT + PLANNED_CLOSE_RAW source PGCT + ACTUAL_OPEN_RAW source GOTM + ACTUAL_CLOSE_RAW source GCTM + RESOURCE_TYPE source GTYP + [typed timestamps / presence data as required] + + PK (FLID, ORDINAL) + INDEX (GATE_CODE, FLID) when resource lookup is required +``` + +`SOURCE_SEQ` 不强转整数，以免丢掉契约/legacy 需要保留的形式。`ORDINAL` 是当前集合内部位置，不承诺跨版本稳定身份。若某报文是按序号逐项变更，必须由其业务规则使用源序号定位，并单独验证重复序号。 + +子表 FK 可随主表删除级联，以保证删除完整；对资源主数据的引用建议先做软校验和未知代码可观测性，避免参考数据刷新滞后使整个 FIFO 卡住。引用完整性是否升级硬约束需结合上游保证。 + +### 8.4 标量类型与时区 + +SIS 的时间示例是 `DDMONYYHHMM` 当地时间（例如 GTDT 的定义），不能因为 AIDX 使用 UTC 就直接给 SIS 字符串加 Z。应使用明确的 `Asia/Shanghai` 和英文月份解析，定义两位年份的世纪窗口，保留原字符串；测试跨月、跨年、午夜和非法值。其他机场接入时必须重新绑定时区。 + +高频查询使用标准化时间列；原始 SODT 字符串的字典序不等于时间序。PG 使用相应时区时间类型，Oracle 使用经过验证的 TIMESTAMP 类型与 JDBC 绑定；保留机场时区配置，不能认为数据库保存了瞬间就保存了源业务时区。 + +FTSS、取消、异常、资源操作里程碑也不要合成一个强制单向状态机。来自外部的更正消息可以修正历史值，哪些允许更正由 KEEP/FIX 矩阵决定。 + +## 9. 写入与消息语义 + +建议将模块边界调整为： + +```text +SIS XML -> 契约解码与校验 -> 类型明确的命令 + | + 当前态 + 纯 Handler -> nextState / 通知意图 + | + 同一自有库事务：主表 + 明细 + generation + outbox + SUCCEEDED + | + 提交后回填补偿 / 至少一次投递 +``` + +### 9.1 明确操作，不让仓储推测 + +| 输入情况 | 标量动作 | 集合动作 | +|---|---|---| +| 字段/集合未出现 | 不修改 | 不修改 | +| 合法值出现 | Set(value) | 对被确认是集合快照的类型，Replace(完整列表) | +| 明确删除标记 | Clear | Clear，按线协议输出明确的清除表达 | +| 操作型消息 | 按该类型规则 | 按序号更新、追加或替换由逐类型契约决定 | +| 非法对象、未知属性、超容量 | 可诊断失败 | 禁止成功后悄悄丢弃；是否可扩展接收由版本策略决定 | + +GTDT/CKDT 的“0=全部未分配”在本地 SIS 文档有依据；不能直接推广为所有类型的序号 0 都有同样含义。ABTM/CHOT 尤其需要确认报文携带操作全集还是本次变化。AIDX 的重复元素约定可帮助设计，但不能替代 SIS 实测。 + +`Clear` 后数据库与 wire 是否输出 `[]`、`null` 或协议专属标记，必须按下游契约固定；本轮不擅自改变 Kafka 线格式。 + +### 9.2 保持原子性与 FIFO 的提交顺序 + +1. 锁外解析并验证完整消息，生成不依赖当前态的命令；快照整包校验重复 FLID、日域和集合边界。 +2. 开自有库事务，取得 writer 行锁。 +3. 锁内复核队头与消息终态；已成功的同一消息直接结束业务应用，不增加版本/事件。 +4. 读取当前航班与 generation，调用纯函数计算下一状态。 +5. 写主表和受影响的明细；快照进行 FDAY 域化差删、版本和成员推进。CAS 失败即回滚。 +6. 从同一个完整状态产生 outbox；记录必要身份和版本；置 SUCCEEDED。 +7. 提交后独立执行回填/投递；其失败不回退业务终态。 + +集合替换可在同一事务内 `DELETE WHERE FLID=?` 后 JDBC batch INSERT。小集合无需先实现复杂行级 diff；其他连接只能看到已提交状态，但多条 SELECT 的组装仍需一致读取策略。 + +DNLD 删除某航班后，下游如何得知删除也需要验收：显式删除通知、整批替换标记或重新拉取必须选定一种。当前 `SnapshotFlow` 只为新集合构造 schd 事件，不能只验收数据库少了一行。 + +## 10. 查询与展示：避免把屏幕列数写成业务上限 + +项目当前没有前端，现有输出是 `/all/flights` 与 Kafka。所谓运营“显示”应落实为它们的读模型，而非凭空增加 UI。 + +兼容 API 可以继续提供原来的 FLTR/字段结构，仓储聚合主表和明细。DBA 需要首个/第二个登机门时，提供 `FLIGHT_SCHD_DISPLAY` 查询视图，额外给出 `GATE_COUNT`，并保留完整明细查询。主表无需新增任意数量的 `GATE3...99`。 + +实现时注意： + +- 不把多个 1:N 表直接 JOIN 成一个巨大的结果；三个门乘四个柜台再乘两个转盘会重复行。 +- 主表分页后，按 FLID 批量读取各类明细并组装，避免每航班 N+1 查询。 +- 父子表分多次 SELECT 时使用同一一致快照，或读取版本并重试；否则可能混合更新前的主表与更新后的明细。PG/Oracle 分别验收隔离行为。 +- `MAID` 过滤保留现有共享航班查询契约。共享记录、实际承运信息和营销航班关系不要合并成单一文本标签。 +- 资源反查索引通常从 `(resource_code, flid)` 出发；航班列表按实际日期/进离港筛选建立组合索引。用真实查询计划确定，不是把所有宽表列都加 B-tree。 +- `/all/flights` 的兼容全量接口先保留；需要新增分页接口时另定 API 契约，不能悄悄把原接口改成只返回第一页。 + +性能验收应测报文峰值、最大 DNLD、每类集合 p95/p99/最大值、事务 p95/p99、锁等待、提交日志量、查询组装成本和消息积压。只有生产样本分布，不能证明业务硬上限；同时要有协议边界测试。 + +## 11. 分阶段迁移与回退 + +| 阶段 | 具体工作 | 完成证据 | +|---|---|---| +| P0：契约和阻断项 | 建立 16 类集合的缺失/清空/替换/操作矩阵；修 CAS、提交后回填边界；恢复完整集合承载能力。 | 三门、多舱柜台、多次桥/轮挡、异常清除、两快照冲突都通过。 | +| P1：无损扩展 | 增加明细/过渡旁表；保留现有展示列；建立版本和来源追踪；增量写同库同事务。 | 新旧读取与源完整状态对比，所有合法输入无静默损失。 | +| P2：数据回填与切换 | 按已部署版本选择回填来源，完整校验后切读；保留旧结构一个回退窗口。 | 数量、属性、顺序、空值、状态及 outbox 载荷核对；无未解释偏差。 | +| P3：双数据库验收 | 分别提供 PG/Oracle DDL/DML、迁移与集成环境；业务契约用同一组测试。 | 两套隔离环境均通过；11g 驱动/JDK/迁移组合已实际验证。 | +| P4：查询优化与收尾 | 按负载加索引/展示视图，移除确认不再使用的损失性列与转换函数。 | 查询计划和时延达标；回退窗口关闭、数据备份可恢复。 | + +不同安装状态必须区别处理： + +- **空库**：可新建正确结构，但仍需通过升级链的空库安装测试。 +- **V1.1.0 有数据、尚未到 V1.2.0**：必须在 DROP 之前保存完整集合；由原 `*_TXT` 回填并对拍。 +- **V1.2.0 已运行**：固定槽位里缺失的第三个门、源序号等不可从现表推算回来。需要旧库备份、完整历史输入或可信的完整快照。新的 DNLD 只能恢复它包含的当前态，不能保证恢复全部历史操作。 +- **回放恢复**：进入隔离库、隔离投递目标；先重建并核对水位，再受控切换。不能把旧消息直接灌回实时 FIFO 覆盖新状态。 + +PG→Oracle 切换不做两个权威库之间的实时应用双写。以停写水位、待投递事件状态、完整导出、目标导入对拍和单活动实例切换为基本路线；具体停机窗口与回退点待部署资料确定。 + +## 12. 验证结果与还缺什么 + +### 12.1 本轮已执行 + +使用 JDK 25 执行： + +```sh +GRADLE_USER_HOME=/home/windy/project/msgexchange-v2/.gradle-home \ +TMPDIR=/home/windy/project/msgexchange-v2/.gradletmp \ +./gradlew test \ + --tests '*FlightSchdInvariantTest' \ + --tests '*FlightStoreDiffToolTest' \ + --tests '*FlightFieldsJsonTest' +``` + +结果：**13 tests，0 failures，0 errors，0 skipped**。分别为 6 个状态不变量测试、5 个对拍测试、2 个序列化测试。初次沙箱运行因 Gradle 本机网络绑定失败；离线重试缺依赖；授权的在线运行成功。编译存在既有弃用/注解警告，没有据此修改依赖。 + +另以临时 Java 诊断直接调用本次编译产物中的 `flattenForStorage` 和 `mapFlightRow`。DataSource 代理禁止任何数据库调用，ResultSet 为内存字段映射；这是转换级诊断，不是 JDBC 集成测试。复现结果： + +| 输入 | 实际观察 | +|---|---| +| 三条 GTDT：G28/G33/G23 | 读回两条，G23 丢失 | +| 单条 GTNO=3 | 读回 GTNO=1 | +| 同 CHKC 的 F/Y 两条分配 | 读回一条 | +| 两次靠桥、不同 ASNO/ABDG | 只余一次，原桥号和源序号消失 | +| GTDT=[] | 读回没有 GTDT 键 | +| FRET=null | 没有生成任何清空列 | +| DELY 两条原因 | 读回首条 | + +这解释了为什么既有测试全绿不足以支持“100% 保真”：相关测试未覆盖上述反例，stub 也没有模拟 JDBC 的损失性表示。 + +### 12.2 尚未执行及原因 + +- 未执行全部测试及现有 `FlightSchdJdbcPgTest`。其 `setUp` 固定连接本机 `msgx`，`cleanup:70` 删除 `TEST_%` 航班及 `2026-09-01` 以后的 generation；未确认隔离性，不应在设计评审中直接运行该清场逻辑。 +- 该 JDBC 测试在连接不可用时会 `assumeTrue` 跳过，当前构建没有以 Testcontainers 提供隔离 PG 的证据；因此文档中的集成验收措辞不能只看总任务绿色。 +- 未连接 Oracle 11g；没有驱动/JDK/迁移工具兼容验收，没有带真实数据迁移、跨连接并发和恢复性能结果。 +- 没有现场真实流量分布或双机场 FLID 唯一性材料。文档声称的现场规律与本轮可核验事实分开记录。 + +### 12.3 实施时必需的回归矩阵 + +| 类别 | 至少覆盖 | +|---|---| +| 契约往返 | 三门、99 条允许集合、重复资源不同舱位、非连续源序号、顺序、每个可选属性、中文长文本 | +| 空值 | 未出现、空串、NULL、空数组、0 删除标记、异常对象清除；PG 与 Oracle 同语义 | +| 操作 | 多次靠撤桥/轮挡、更正原操作、不同桥/机位、多个延误、路线空属性 | +| 快照 | 同 FLID 重复、跨日归属、ADFT 存活、空快照、非法快照整包拒绝、响应匹配 | +| 事务 | 任意明细/outbox 写失败全回滚；generation 内容与版本一致；不同消息争同一下一版本必须冲突 | +| 恢复 | 提交成功后回填失败不重做业务；重放不加版本和事件；下游已接收可去重 | +| 多连接 | 锁等待、断连释放、读后写冲突、不能跳过 FIFO；不能只用内存 mock 证明 | +| 迁移 | 有数据 V1.1→目标、V1.2 损失检查、故障恢复、回退窗口、两数据库新建/升级 | +| 查询/投递 | 父子状态一致读取、全量接口保兼容、无 N+1/笛卡尔积、删除可见、DB 与 wire 等价 | + +对拍工具继续保留严格默认：不通过忽略 GTNO、忽略第三个资源、忽略 ABDG 等方式把有损转换“洗绿”。任何合法偏离必须有业务依据、明确范围和黄金样例。 + +## 13. Plane workflow 对齐与后续落点 + +已按 `plane-workflow` 读取 ACM2-28 与 ACM2-29，确认属于 ACM2 项目；并搜索已有航班主题工作项。没有新建任务、修改状态或发表评论。 + +- **ACM2-28** 的单库权威决策可以保留；RPO、完成清单和当前平台措辞应按本评审限定。 +- **ACM2-29** 直接覆盖本次问题，但其中“全系统零子表”“100% 吻合”“零方言包袱”等验收标准需要修订为可测的不变量。 +- 建议将后续工作拆为：契约保真与安全存储、快照/回填事务修正、有数据迁移、Oracle 11g 适配、读模型与查询验收。工作项依赖应在获授权写入时建立 Plane relation，不靠标题排序替代依赖。 +- 本轮用户已明确的部署条件应写入后续平台方案，不再重复询问是否可能是 Oracle 12c/19c；仍需的是实际 11.2 补丁、字符集、权限和可测试环境。 + +**评审意见：ACM2-28 的一致性方向通过；ACM2-29 的损失性宽表方案不建议作为生产权威形态验收。优先完成无损表示和事务恢复，再扩展批量 Handler。**