-- tier2/config/schema/tier2_source_project_version.sql
-- ════════════════════════════════════════════════════════════════════════════
-- tier2 富游戏自治生成线 · 第二装载落库(U2)源工程版本表。
--
-- 【这张表解决什么】
--   F 族要素⑦ addressing:把 finish 交付的源工程 manifest(七要素去掉 fileTree 各文件 content)
--   落 MySQL 一行,按 (game_id, source_hash) 幂等、按 (game_id, version_id) 取回寻址。源文件全文
--   (fileTree 各文件 content)不进本表,落 MinIO(S3 兼容 OSS),manifest.addressing.sourceUrl 指向
--   MinIO 版本前缀。改源重建 → 新 version_id,旧版本保留(F1 版本寻址 / 游戏=长生命周期项目)。
--
-- 【与代码的关系 · 同源对账门】
--   worker/store.py 的 BackendStore._ensure_schema 首次 save 时会执行等价的 CREATE TABLE IF NOT EXISTS
--   (代码内自建,见 _DDL_SOURCE_PROJECT_VERSION),并按 information_schema 探测缺 status 列则补跑
--   _ALTER_ADD_STATUS_COLUMN(= 本文件末尾那条 ALTER),故部署不强制先手动跑本文件。本文件是同源的
--   【可审阅 DDL 留档】:DBA / 后端接线 / 评审按它对账表结构;若手工预建,在 tier2 库执行本文件即可
--   (代码再跑 IF NOT EXISTS / 探测不会重建重加)。in-code DDL 与本文件双源,由
--   tests/test_store_ddl_reconcile.py 规范化对账钉成机器门:改一处漏改另一处即红,不靠人肉纪律。
--   表所在库 = infra.yaml mysql.database(默认 tier2;与 game-cloud 业务库隔离)。
--
-- 【治理归属】本表 owner = tier2 生成线,不走 game-cloud 的 huijing Flyway、无执行副本,故 .sql 留在
--   本目录(tier2/config/schema/)、不塞 contracts/db-schemas/ 根(那是 huijing Flyway 授权源、须与
--   game-cloud 执行副本 diff 一致)。治理指针登记在 contracts/README.md 指针登记集群「tier2 自有受治理 schema」。
--
-- 【MinIO key 约定(与本表配套,不在本 DDL 内)】
--   object key = <game_id>/<version_id>/<工程内相对路径>,bucket = infra.yaml minio.bucket(默认 tier2-src)。
-- ════════════════════════════════════════════════════════════════════════════

CREATE TABLE IF NOT EXISTS tier2_source_project_version (
    id            BIGINT       NOT NULL AUTO_INCREMENT COMMENT '自增主键',
    game_id       VARCHAR(128) NOT NULL                COMMENT '游戏稳定标识(同款多版本共享;落库 id)',
    version_id    VARCHAR(96)  NOT NULL                COMMENT '版本号 vXXXX-hash12(改源重建生成新版本)',
    source_hash   CHAR(64)     NOT NULL                COMMENT '源工程内容指纹 sha256(= source_project.contentHash;幂等键)',
    manifest_json LONGTEXT     NOT NULL                COMMENT '源工程 manifest 七要素形状(去 fileTree content;含 addressing)',
    addressing    VARCHAR(512) NULL                    COMMENT '落库寻址摘要(store/sourceUrl;冗余出 manifest 便于检索)',
    created_at    DATETIME     NOT NULL                COMMENT '落库时刻(now_ts 转 UTC datetime)',
    status        VARCHAR(16)  NOT NULL DEFAULT 'committed' COMMENT 'manifest-first 落库状态:pending=已占位未提交(半落库可见残行)/committed=源文件已全落可取回;fetch 只返 committed',
    PRIMARY KEY (id),
    UNIQUE KEY uk_game_source (game_id, source_hash)   COMMENT '幂等键:同款同源不重复落',
    UNIQUE KEY uk_game_version (game_id, version_id)    COMMENT '版本寻址键:同款版本号唯一',
    KEY idx_game_created (game_id, created_at)          COMMENT 'fetch 取最新版本走它'
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='tier2 富游戏源工程版本表(U2 第二装载落库)';

-- ── status 列受治理迁移(这张表第一份 ALTER)──────────────────────────────────────────
--   为什么单列这条:上面的 CREATE TABLE IF NOT EXISTS 对【已存在】的旧表加不了列,历史窗口里已建的无
--   status 列旧表靠 CREATE 永远补不上。故对存量表跑这条 ALTER 补列(新装已由上面 CREATE 直接带 status,
--   不需要这条)。DEFAULT 'committed' 兜历史行(历史落进来的都是完整版本,视作已提交);新写入路径按
--   manifest-first 时序显式置 pending/committed,不吃 DEFAULT。
--   in-code 对应 worker/store.py 的 _ALTER_ADD_STATUS_COLUMN,由 BackendStore._ensure_schema 按
--   information_schema 探测缺列才跑(幂等)。本条与该常量由 tests/test_store_ddl_reconcile.py 规范化对账。
ALTER TABLE tier2_source_project_version ADD COLUMN status VARCHAR(16) NOT NULL DEFAULT 'committed';