2.6 KiB
2.6 KiB
B5-3 comment* 三集合决策报告（需人工确认，执行模型未自动执行）
现状：comment / comment_like / comment_operation_logs 在仓库内无任何 schema，
但三页完整实现了增删改查。门禁 fieldDriftCount: 20 全部来自这三集合（missing-in-schema）。
页面实际字段（来自 list.vue field）
| 集合 | 字段 |
|---|---|
| comment | content, root_id, author_id, parent_id, article_id, like_count, create_time, update_time, reply_count, ip_location |
| comment_like | user_id, comment_id, create_time |
| comment_operation_logs | parent_id, user_id, content, like_count, create_time, update_time, status |
官方 opendb-news-comments 字段（仓库内现有 schema）
_id, article_id, user_id, comment_content, like_count, comment_type, reply_user_id, reply_comment_id, comment_date, comment_ip
方案 A：新建 3 份 schema（按页面字段）
- 动作：补
comment.schema.json+comment_like.schema.json+comment_operation_logs.schema.json（权限 + 索引），上传后门禁 20 条漂移清零。 - 风险：若云端实际用的是
opendb-news-comments，会造成双写分裂（两套评论表并存）。 - 成本：小，纯新增文件，不碰页面。
方案 B：页面改用官方表 opendb-news-comments
字段映射（差异大）：
| 页面字段（comment） | 官方字段 | 说明 |
|---|---|---|
| content | comment_content | 改名 |
| create_time | comment_date | 改名（类型需核对 timestamp vs date） |
| author_id | user_id | 改名 |
| root_id / parent_id | reply_comment_id | 语义不完全等同，需确认盖楼模型 |
| article_id | article_id | 同名 |
| like_count | like_count | 同名 |
| reply_count / update_time / ip_location | 无 | 官方表无对应，需加字段或弃用 |
| — | comment_type / reply_user_id / comment_ip | 页面无对应，需确认是否需要 |
- 风险：字段语义差异大，改完需重建/迁移数据；
comment_like与comment_operation_logs在官方体系无对应表，需另行设计。 - 成本：大，涉及页面 field、表单、查询条件全改 + 数据迁移。
建议
缺云端真相时倾向 A（新建 schema）：先让三页有合同可依，门禁清零；
待确认云端真实用表后再做合并迁移。若云端已在用 opendb-news-comments 且有数据，
则选 B，但必须先出数据迁移脚本再改页面。
确认后执行清单
- 选 A：新建 3 份 schema + 3 份 index + init 权限（如需细粒度），跑
npm run check:contracts验收漂移清零。 - 选 B：改三页 field/表单/查询 + 迁移脚本 + 重跑门禁 + changelog 标注破坏性变更。