 ThearchyHelios
|
8d59ca1581
|
W3-a 表结构变化：前后差异、影响面、结构版本与 schema.drift（next-round 03 B1）
以前重新探查是整份替换表结构、不比前后：删了一列，那一列上人工确认过的目录项、写死这一列的已发布模板都收不到提醒，
正式运行要到查询那一步才报错。现在：
- data/schema_diff.py：纯函数，同一张表前后两次的结构比出变化（加列、删列、类型、可空、注释、主键与唯一约束、外键）；
疑似改名（类型相同、夹在同样两列之间、只有一对）只说「可能」；读不到唯一约束、外键的一边不比；升级后第一次读到
（结构版本 0）只建基线，不把通用写法换成方言完整写法说成类型变了。
- 后台探查顺带记变化（data/introspect_jobs.py）：刷新对象索引记新出现的表、真删除的表（第一次建索引只建基线）；开始
执行时记离开范围的有目录的表、范围规则和上一次不同；逐批读完拿上一次的结构比，读不到结构的记 table_reflect_failed。
离开范围、读不到结构不算删除。记变化出错只记日志，不挡探查。
- 变化记录 source_changes（db/models_sources.py 的 SourceChange，格式 agentlab-change/1，seq 自增不复用、按指纹去重），
记录与读取在 data/source_changes.py；取值观察的表 TableObservation 同文件建好。
- 影响面（data/catalog_impact.structure_impact）：目录里说到被删、被改的列的项（列级项、业务主键、业务日期、有效记录条件
按 parse_valid_filter 取列、两端的关联关系）带状态，人工确认过的升为要处理；已发布模板写死的 SQL 换上新结构再跑
sql_unknown_columns，说得出「这条 SQL 现在会报列不存在」。sql_unknown_columns 从 api/copilot.py 挪到
data/sqlcheck_columns.py 共用，copilot 那边只改 import。
- 发布时记 WorkflowVersion.schema_versions（只记直接引用、结构版本大于 0 的表）；正式运行发起时比对，变了写 schema.drift
（core/events.py 登记，只提醒、不拦）；版本详情给出 schema_versions、schema_changes；发布前检查把这一版直接引用的表上
还没处理的结构变化列成警告（schema.change_open），不拦发布。
测试：test_schema_diff（纯函数）、test_schema_changes（SQLite 夹具 ALTER 前后、影响面、去重、真删除与离开范围、
schema.drift、发布前检查、升级后基线）。
|
2026-10-16 16:26:11 +08:00 |
|
|
ThearchyHelios
|
298e52bd69
|
按复核意见修后台探查的三处退化（A-1、A-2、A-3）
A-1 升级后第一次后台探查中途停下，表结构缩成已读完的那几批：
schema_cache 只从对象索引物化，老缓存（升级前同步探查写的，没有 scope 摘要）里的表结构却从没进过对象索引。
于是第一次探查只要停止、连接断开、服务重启，或者排队时有人按需加入、探查失败要记一笔，物化出来的就只剩已读完的表，
老缓存里还没重读的表静默消失，skipped 里也没有。先在探查范围面板刷新过对象索引、再探查却连不上时更糟：表结构清成空的。
现在这个 schema 的对象索引第一次建起来时（refresh_index 的 legacy，source_objects.legacy_seed），把老缓存里的表结构
接进对应的行：在范围里、算规则命中，带老结构和它的指纹，结构版本记 0（第一次真读到记 1，不把反射格式的差异当成
结构变化）；老缓存里读不到结构的照样记成读不到。缓存的 schema 和配置对不上的不接，对象索引里没有的不接。第一次
任务开始时照规则重圈，没重读到的沿用老结构，和以后每次探查中途停下一样。
A-2 schema 填错、一个对象都没有时不再给候选 schema：
PostgreSQL、Oracle 的 schema 写错时字典查询只回 0 行，不抛错，新路径就只物化出 tables={} 并盖上同步时间，
available_schemas 没了：卡片上「该服务器上还有……」、助手摘要里「数据可能在这些 schema」都给不出。现在 prepare
拿到 0 个对象时照旧用 list_schemas 拿候选，记在任务的 scope 里，物化时由 rebuild_schema_cache 写进 available_schemas
（不置 failed：这不是一次失败）；有了对象再探查就不再挂着。
A-3 排队中「加入范围」的表在任务开始时被移出：
_apply 只保留建任务时圈好的表和所有 on_demand 的行，目录页显式加入（explicit）的表被当成离开范围、清掉结构。
现在保留 added_at 不早于建任务时刻的行（按需加入、显式加入都算），原因按 pinned > 显式 > 规则 > 按需取高的；
建任务之前就按需加入、又被显式移出的不再一律留着，照规则移出（以前「留着所有 on_demand」会让显式移出不生效）。
测试（tests/test_introspect_jobs.py）：60 张表的老缓存，第一批读完后停止 / 第二批连接出错 / 重启标中断 / dry_run
后探查失败，表数都不减少，再探查一次结构版本全是 1；别的 schema 的老缓存不接；空库和替身模拟的 0 对象 schema 带上
候选、DataSourceOut 和助手摘要都看得到；排队中显式加入、按需加入的表任务跑完仍在范围里。去掉三处修复各自回跑，
对应的测试都失败。
|
2026-10-16 15:36:21 +08:00 |
|
|
ThearchyHelios
|
f9f5338ec6
|
数据源不可用时的 db_schema 替身也收 keyword；重读范围内读不到结构的表不记成按需加入；起草、剖析排在探查后面的测试
- tools/datasource._unavailable_tool：db_schema__ 多了可选的 keyword，固定的版本不在了时的替身也要收这个参数（调用工具节点按
参数模型的全部字段传参，不收就报「不接受名为 keyword 的参数」，全量测试里 test_run_data_versions 抓到的）。
- source_objects.add_to_scope：本来就在范围里、只是上次没读到结构的表（pinned、规则命中的）这次重读一遍，不改原因、不记留痕，
不算进「每次运行最多按需加入 8 张」，也不出现在面板的「按需加入的表」里。
- tests/test_introspect_jobs.py：起草、剖析任务排在同源的探查任务后面时 waiting_for 是 introspect。
|
2026-10-16 14:53:41 +08:00 |
|
|
ThearchyHelios
|
4ba4a21b2c
|
大库的 look 预筛与按需加入、剖析事实四处一致、有效记录条件按 quote_name 加引号的测试；对象索引批量更新改走按表的 executemany
为什么：A2 和遗留 e 的行为要有脚本化的验收，且能证明测试抓得住回归（去掉遮罩重滤、去掉 quote_name 强制引号后对应用例都失败，
已回跑确认）。
- tests/test_look_large.py：3,000 张表的合成库，探查范围 300 张 + 5 张有目录的表，其余只在对象索引里（注释写进索引，模拟
MySQL / PG 的表注释）。10 条脚本化需求挑中 ≥ 9 条、挑选提示词 < 20,000 字（挑选用按字面重合打分的假模型，只看得到交给它的
那份目录）；挑中范围外的表按需加入、记 added_to_scope 和留痕；点名的每次查看最多 4 张、超了照实说；db_schema__ 的 keyword、
只列前 50 张、每次运行最多 8 张；查询照实列「未按目录检查的表」；目录搜索和「加入范围」；剖析的关系指向范围外时不说
「表结构里没有」。
- tests/test_profile_facts.py：look、运行时 db_schema、/schema、表助手四处同一段剖析事实和固定提示；剖析之后加遮罩，那一列
的范围不出现；没有剖析结果时表详情一字不差；上传表格快照不一致（含没记快照的）不给；剖析任务开始一张表时记下快照；
「上次剖析」取真正开始过的那一次。
- tests/test_valid_filter_quote.py：存进目录的写法和剖析核对查询都按 quote_name 给 Oracle 小写列加引号。
- source_objects.refresh_index：注释、类型、行数估算有变的行改用按表的 executemany（ORM 的按主键批量更新要求参数里写主键
列名，3,000 张表的库第二次刷新索引时报错）。
- db_schema__ 不传 table 时说清没列出的里有几张在探查范围外。
|
2026-10-16 14:26:04 +08:00 |
|
|
ThearchyHelios
|
1a6082f033
|
大库的对象索引、探查范围和后台探查（next-round 03 A1），schema_view 预筛与按需加入、剖析事实的后端（A2、遗留 e 的底座）
为什么：几千张表的库以前用不了——探查每个源最多取 200 个对象、按数据库列出的顺序截断，同步请求、整份替换、不排队；
落在窗口外的表在目录、look、剖析里被说成「表已不在」。
做了什么：
- db/models_sources.py：source_objects（对象索引一行一个对象：范围、原因、结构指纹与 struct_version、first_seen / last_seen /
removed_at、reflected_at、按需加入的留痕）、introspect_jobs / introspect_tasks（后台探查任务与逐表状态）。
- data/source_objects.py：每种方言一条字典查询建对象索引（失败退回 Inspector，上限 5 万，截断时不判删除）；探查范围规则
（options.introspect_scope：通配、按 name_key、排除优先、显式列出 / 移出；有目录的表、已发布模板写死 SQL 用到的表 pinned；
命中超上限拒绝并说出命中数）；唯一的 rebuild_schema_cache 从范围内已反射的行物化 schema_cache（形状不变，另加 scope 摘要）；
三种「不在」分开说（removed / missing / out_of_scope / reflect_failed）；按需加入（当场只读反射、落盘、留痕、进程内按源加锁）。
- data/introspect_jobs.py：探查改成后台任务（core/job_runtime，lane kind introspect，和同源起草、剖析串行；按批反射、逐表记状态、
可停止、读完的照样物化；重启标中断不续跑）。
- api/datasources.py：POST /introspect 返回 202 和任务，dry_run 同步只刷新索引、返回命中数；/introspect-jobs 读任务、停止；
/introspect-scope 读、预览、保存规则；/schema?table= 带剖析事实、说清三种「不在」；DataSourceOut 加 schema_scope、introspect_job。
- schema_view：search_tables（BM25 倒排，遮罩列只用列名，范围外只按名字和注释、权重低一档）、profile_lines（剖析事实一节，
附「只供写查询参考」，遮罩按渲染那一刻重滤，上传表格快照不一致时不给）、absent_detail。
- look：候选超过 PREFILTER_LIMIT 时只给预筛结果 + 已用到的表 + 一跳关联；点名或挑中范围外的表按需加入（每次查看最多 4 张），
look 记录加 added_to_scope、prefiltered；表详情带剖析事实。
- tools/datasource：db_schema__ 加 keyword、不传 table 时只列前 50 张；点名范围外的表按需加入（每次运行最多 8 张）；查询结果
照实列「未按目录检查的表」（unchecked_tables，不新增检查规则）；建工具时读剖析事实。
- 剖析：_relation_ends 分清「范围外，可以加入」和「表结构里没有」；任务记上传表格的 snapshot_id；last_facts。表助手、/schema
用同一段剖析事实。
- 目录接口：清单只列范围内，absent_reason 分开说；GET /catalog/search 查对象索引，POST /catalog/scope/add 加入范围。
- 第 1 波留下的一处：check_valid_filter 和 stored_valid_filter 拼有效记录条件时按 quote_name 强制加引号。
- 工具参数纠错：空着的可选参数不止一个时，只认拼写明显接近的那一个（db_schema 多了 keyword 以后 tabel 仍能纠成 table）。
- 测试：3,000 张表的合成库（对象索引、缺省范围超上限拒绝、规则圈 400 张后台读完、停止、重启标中断、和剖析排队、同步起草
409）、删除与结构版本、Inspector 回退、截断不判删除、范围规则、pinned、方言金样；改了同步探查的老测试改为等任务做完。
|
2026-10-16 14:17:06 +08:00 |
|