auto_control

164 Commits 2 Branches 6 Tags

2 Commits

Include renames

Author	SHA1	Message	Date
butubb	c834349fac	refactor: schema 收敛到 ORM metadata——5 张裸表升模型，方言无关的建表/补列/唯一索引原来建表有三套来源（ORM create_all + 自建 SCHEMA_MIGRATIONS + agent_api 里的裸 CREATE TABLE）。这在 SQLite 下能活是因为 SQLite 的 DDL 极宽容；换 MySQL 后 agent_* 四张表的 `INTEGER PRIMARY KEY AUTOINCREMENT`、`TEXT DEFAULT ''`、 `TEXT PRIMARY KEY` 会全部建不出来，而失败被 `except: pass` 吞掉 —— 表现为「经验库/动作库/会话功能静默失灵、日志里什么都看不到」。本期把它收敛成一套。 - core/models.py: * 新增 5 个 ORM 模型：AppMeta / AgentExperience / ExperienceAudit / AgentAction / AgentConversation（列名沿用历史，`app_meta.key` 在 MySQL 里是保留字，ORM 属性名用 k，读写统一走 db_config.meta_get/meta_set） * 新增 _long_text()（MySQL 用 MEDIUMTEXT，裸 TEXT 只有 64KB）与 _DOUBLE() （评分别用单精度 FLOAT）；_migrate_schema 不再执行 DDL，只维护版本账本， SCHEMA_MIGRATIONS 的历史建表/加列条目 SQL 置 None * 新增 _sync_columns()：用 sqlalchemy.inspect 比对模型与实表补缺列，取代原来靠 "duplicate column name" 报错文本判断的写法（换方言就失效） * _ensure_unique_indexes() 按方言分叉：MySQL 5.7 没有过滤索引，改用「虚拟生成列 + 唯一索引」复刻"空值不参与唯一约束"的语义 - web/agent_api.py: 删 4 段裸 CREATE TABLE；_ensure_* 收敛为 _ensure_tables() （db.create_all 薄封装，失败必记日志）；app_meta 读写与 INSERT OR IGNORE 改为方言中立 - core/device_discovery.py: app_meta 读写改用同一助手 - core/system_backup.py: SUMMARY_TABLES 由 db.metadata 派生 —— 备份覆盖红线从"靠人记"变成结构上不可能漏；CURRENT_SCHEMA_VERSION 改从 models 导入验证（均在 users.db 的一致快照副本上，不碰真实库）：空库 → 自建 12 张表 + 默认管理员 + 唯一索引 + schema_version=6；老库 → 逐表行数与真实库完全一致，app_meta 键未变；接口 → health/devices/jobs/groups/agent(经验库/动作库/会话) 全 200，会话增删与备份导出（12 张表、无覆盖缺失）正常。	2026-09-13 10:30:15 +08:00
butubb	f22263ab45	feat: 数据库连接层改造——库目标由 .env 装配 + 环境防呆（迁 MySQL 第一步）为把数据库从单文件 SQLite 迁到 MySQL 5.7 铺路。本期不改后端： DB_HOST 为空时仍走 SQLite，本地开发无感。 - config.py: 新增 DEPLOY_ENV（默认 dev）与 DB_HOST/PORT/USER/PASSWORD/NAME/ CHARSET/COLLATION、DATABASE_URL、两个逃生阀（DB_ALLOW_ENV_MISMATCH / DB_ALLOW_SQLITE_FALLBACK） - core/db_config.py（新增）: URI 组装；按方言分叉的引擎参数（utf8mb4、 pool_pre_ping、pool_recycle=1800、READ COMMITTED、STRICT_TRANS_TABLES）；连接探活；app_meta 方言中立读写（MySQL 里 key 是保留字，需反引号） - 防混库三层: ①库名与环境绑定（dev→auto_control_dev / prod→auto_control） ②库标签 app_meta.deployment_env 与 .env 声明比对 ③启动横幅打印当前库（生产用 WARNING 级）。不符直接拒绝启动并说明两边分别是什么 - web_server.py: 硬编码 sqlite URI → db_config；配置错在装配期就 exit 2； init_db 之后跑库标签校验 + 横幅 - core/models.py: PRAGMA 监听器加 sqlite 类型守卫——它挂在 Engine 基类上， MySQL 连接执行 PRAGMA 会直接导致建连失败 - requirements.txt 加 PyMySQL；scripts/start.sh 依赖守卫加 pymysql，并在 exec 前打印 DEPLOY_ENV/DB_NAME/DB_HOST - .env.example 新增「数据库」段；DEVELOPMENT.md §4.1/4.2、DEPLOY.md §2.2 同步验证: 用 DATABASE_URL 指向 users.db 的一致快照副本跑通主要只读接口（health/devices/jobs/pool/groups/discovery/summary 全 200，app_meta 读写正常）； DEPLOY_ENV=prod 且无 DB_HOST 时退出码 2；开 DB_ALLOW_SQLITE_FALLBACK 后可回退。	2026-09-13 10:27:14 +08:00

Author

SHA1

Message

Date

butubb

c834349fac

refactor: schema 收敛到 ORM metadata——5 张裸表升模型，方言无关的建表/补列/唯一索引

原来建表有三套来源（ORM create_all + 自建 SCHEMA_MIGRATIONS + agent_api 里的裸
CREATE TABLE）。这在 SQLite 下能活是因为 SQLite 的 DDL 极宽容；换 MySQL 后
agent_* 四张表的 `INTEGER PRIMARY KEY AUTOINCREMENT`、`TEXT DEFAULT ''`、
`TEXT PRIMARY KEY` 会全部建不出来，而失败被 `except: pass` 吞掉 —— 表现为
「经验库/动作库/会话功能静默失灵、日志里什么都看不到」。本期把它收敛成一套。

- core/models.py:
  * 新增 5 个 ORM 模型：AppMeta / AgentExperience / ExperienceAudit /
    AgentAction / AgentConversation（列名沿用历史，`app_meta.key` 在 MySQL 里是
    保留字，ORM 属性名用 k，读写统一走 db_config.meta_get/meta_set）
  * 新增 _long_text()（MySQL 用 MEDIUMTEXT，裸 TEXT 只有 64KB）与 _DOUBLE()
    （评分别用单精度 FLOAT）；_migrate_schema 不再执行 DDL，只维护版本账本，
    SCHEMA_MIGRATIONS 的历史建表/加列条目 SQL 置 None
  * 新增 _sync_columns()：用 sqlalchemy.inspect 比对模型与实表补缺列，取代原来
    靠 "duplicate column name" 报错文本判断的写法（换方言就失效）
  * _ensure_unique_indexes() 按方言分叉：MySQL 5.7 没有过滤索引，改用
    「虚拟生成列 + 唯一索引」复刻"空值不参与唯一约束"的语义
- web/agent_api.py: 删 4 段裸 CREATE TABLE；_ensure_* 收敛为 _ensure_tables()
  （db.create_all 薄封装，失败必记日志）；app_meta 读写与 INSERT OR IGNORE
  改为方言中立
- core/device_discovery.py: app_meta 读写改用同一助手
- core/system_backup.py: SUMMARY_TABLES 由 db.metadata 派生 —— 备份覆盖红线
  从"靠人记"变成结构上不可能漏；CURRENT_SCHEMA_VERSION 改从 models 导入

验证（均在 users.db 的一致快照副本上，不碰真实库）：
  空库 → 自建 12 张表 + 默认管理员 + 唯一索引 + schema_version=6；
  老库 → 逐表行数与真实库完全一致，app_meta 键未变；
  接口 → health/devices/jobs/groups/agent(经验库/动作库/会话) 全 200，
        会话增删与备份导出（12 张表、无覆盖缺失）正常。

2026-09-13 10:30:15 +08:00

butubb

f22263ab45

feat: 数据库连接层改造——库目标由 .env 装配 + 环境防呆（迁 MySQL 第一步）

为把数据库从单文件 SQLite 迁到 MySQL 5.7 铺路。本期不改后端：
DB_HOST 为空时仍走 SQLite，本地开发无感。

- config.py: 新增 DEPLOY_ENV（默认 dev）与 DB_HOST/PORT/USER/PASSWORD/NAME/
  CHARSET/COLLATION、DATABASE_URL、两个逃生阀（DB_ALLOW_ENV_MISMATCH /
  DB_ALLOW_SQLITE_FALLBACK）
- core/db_config.py（新增）: URI 组装；按方言分叉的引擎参数（utf8mb4、
  pool_pre_ping、pool_recycle=1800、READ COMMITTED、STRICT_TRANS_TABLES）；
  连接探活；app_meta 方言中立读写（MySQL 里 key 是保留字，需反引号）
- 防混库三层: ①库名与环境绑定（dev→auto_control_dev / prod→auto_control）
  ②库标签 app_meta.deployment_env 与 .env 声明比对 ③启动横幅打印当前库
  （生产用 WARNING 级）。不符直接拒绝启动并说明两边分别是什么
- web_server.py: 硬编码 sqlite URI → db_config；配置错在装配期就 exit 2；
  init_db 之后跑库标签校验 + 横幅
- core/models.py: PRAGMA 监听器加 sqlite 类型守卫——它挂在 Engine 基类上，
  MySQL 连接执行 PRAGMA 会直接导致建连失败
- requirements.txt 加 PyMySQL；scripts/start.sh 依赖守卫加 pymysql，
  并在 exec 前打印 DEPLOY_ENV/DB_NAME/DB_HOST
- .env.example 新增「数据库」段；DEVELOPMENT.md §4.1/4.2、DEPLOY.md §2.2 同步

验证: 用 DATABASE_URL 指向 users.db 的一致快照副本跑通主要只读接口
（health/devices/jobs/pool/groups/discovery/summary 全 200，app_meta 读写正常）；
DEPLOY_ENV=prod 且无 DB_HOST 时退出码 2；开 DB_ALLOW_SQLITE_FALLBACK 后可回退。

2026-09-13 10:27:14 +08:00