### 后端修复:日志表不该用软删除 channel_monitor_histories / channel_monitor_daily_rollups 都是日志/聚合表, 没有恢复需求。110 里加的 SoftDeleteMixin 会让 DELETE 自动变成 UPDATE deleted_at, 导致行和索引只增不减,徒增磁盘占用和查询成本。 改回分批物理删(参考 OpsCleanupService.deleteOldRowsByID 模板): - ent schema 移除 SoftDeleteMixin,重新 go generate - repo 新增 deleteChannelMonitorBatched 辅助 + 两条 prune SQL 常量 (WITH batch AS SELECT id LIMIT 5000 → DELETE IN batch) - DeleteHistoryBefore / DeleteRollupsBefore 改调分批 raw SQL - 移除 ComputeAvailability / ComputeAvailabilityForMonitors / UpsertDailyRollupsFor / ListLatestPerModel / ListLatestForMonitorIDs / ListRecentHistoryForMonitors 等 raw SQL 中的 deleted_at IS NULL 过滤 - UpsertDailyRollupsFor 的 ON CONFLICT 去掉 deleted_at = NULL 重置 - migration 111 DROP COLUMN deleted_at + 对应索引(110 已部署但 maintenance 首跑在次日 02:00,此时尚无业务数据在依赖软删除) ### 前端重构:feature flag 声明式 + 复用 AppSidebar.vue 里 7 处 `...(flag ? [item] : [])` 样板代码删光,改为 NavItem 加 featureFlag?: () => boolean | undefined 字段,加一个 applyFeatureFlags 递归 过滤(含 children)。语义统一为 `!== false`(宽容策略,undefined 时默认显示, 避免 public settings 未加载完成时菜单闪烁消失 — 对应用户反馈"刷新后菜单消失 要去保存设置才回来")。 - 集中声明 4 个 flag getter:flagChannelMonitor / flagPayment / flagOpsMonitoring / flagAdminPayment - 提取 buildSelfNavItems 复用用户端主菜单和管理员"我的账户"子菜单 - 未来新增开关:在统一位置加一个 flag getter + 给对应 NavItem 加字段 (不用再动渲染逻辑) bump 0.1.114.29
17 lines
868 B
SQL
17 lines
868 B
SQL
-- Migration: 127_drop_channel_monitor_deleted_at
|
||
-- 纠正 110 引入的 SoftDeleteMixin:日志/聚合表无恢复需求,软删会让行和索引只增不减,
|
||
-- 徒增磁盘和查询开销。改回分批物理删(由 OpsCleanupService 每天凌晨统一调度,
|
||
-- deleteOldRowsByID 模板,batch=5000)。
|
||
--
|
||
-- 110 尚未跑过聚合/清理(首次 maintenance 在次日 02:00),所以此处不担心业务数据。
|
||
-- 直接 DROP 列 + 索引;对应的 Go 侧 ent schema 已移除 SoftDeleteMixin、repo 的
|
||
-- raw SQL 已移除 deleted_at IS NULL 过滤。
|
||
|
||
DROP INDEX IF EXISTS idx_channel_monitor_histories_deleted_at;
|
||
ALTER TABLE channel_monitor_histories
|
||
DROP COLUMN IF EXISTS deleted_at;
|
||
|
||
DROP INDEX IF EXISTS idx_channel_monitor_daily_rollups_deleted_at;
|
||
ALTER TABLE channel_monitor_daily_rollups
|
||
DROP COLUMN IF EXISTS deleted_at;
|