ThearchyHelios
|
ad1092900c
|
剖析的关系覆盖率把对不上类型的键算作没对上;升级前旧说法的剖析备注不再让目录升版本
复核发现两处(C-relation-coverage-inflated、C-profile-note-rewording-bumps-catalog):
一、覆盖率虚高。key_literals 把父列是数字、子列取到的不是整数写法的文字('WALKIN'、'GUEST0')从覆盖率的
分母里拿掉了:散客代号占九成的一列只剩 1 个整数写法的键对上,就测成覆盖率 100%、升为「已核实」,模型的
db_schema、自查、冻结快照都会照这条错的关系写 join。基线上同一份数据是 proposed、覆盖率 3.1%。
- 整数主键里永远没有这些文字,它们照样是子表的键值,算作没对上、留在分母里:
覆盖率 = 对上的 / (拼进 IN 的 + 按类型就对不上的)。全都不是整数写法时不发父表的核对查询,覆盖率 0%、
「可能不是这条关系」,不再整条判「无法核对」。
- key_literals 改回 KeyLiterals(literals, unmatchable, unsafe):不能安全拼进 SQL 的值单独计数,不再用
「取到的 − 拼进的 − 不同类型的」倒推('0012' 和 '12' 写成同一个字面量时会被错说成「类型不支持核对」)。
- 被指向列是日期时间的关系整条跳过,并且在发子表取值查询之前就跳过、不占这张表的查询预算;说明改成
「各库的时间写法和精度不同,不核对这种关系的覆盖率」——子表一侧也是时间时,以前写的「两端类型不同」不照实。
- 备注里「另有 N 个键值和被指向列的类型不同,未计入」改成「其中 N 个不是整数写法,被指向列是数字,算作没对上」。
- 报告里覆盖率不足的那句「抽样覆盖率 N,保持推断」也改成「覆盖率 N」,和备注一种说法。
二、升级后第一次重新剖析,数据没变也给每张有剖析结论的表升一个版本。剖析备注改了四处说法(抽样覆盖率→
覆盖率、子表抽样→子表取了、(只看前→(按存储顺序只看前、按前 N 行统计→按存储顺序取前 N 行统计),
catalog.same_profile_note 没认成同一句,已发布工作流记下的目录版本对不上,之后每次正式运行都报
catalog.drift。
- same_profile_note 比较前先把这四处固定句式的旧写法换成现在的写法(_LEGACY_PROFILE_WORDING,句式带着前后文
匹配,不会误换人写的原话);算相同时保留目录里的旧备注,旧说法等结论真变了、重写备注时才换掉。
- 起草时核对有效行过滤写在模型依据后面的那句「剖析核对:按前 N 行统计」同样只认那一句的旧写法。
- MySQL / MariaDB 上新加的排序规则说明、ENUM 列定义里没出现的取值、无效日期个数是新信息,这些备注照常
升一次版本,要写进发版说明。
测试:test_catalog_profile 加文字键指向整数主键的端到端用例(去掉修复回跑:测成 verified、覆盖率 100%);
test_profile_dialect_units 加覆盖率分母、时间键不发查询、unsafe 计数的单测;test_catalog_semantics 加跨版本
用例(把剖析备注改回旧说法写进目录、同样的数据重新剖析,版本号和目录都不变;去掉规整回跑两条失败)。
|
2026-10-16 12:02:41 +08:00 |
|
ThearchyHelios
|
ee7b8b2f97
|
剖析与探查的方言修正(C1)和没有真库时的方言验证(C2)
为什么:剖析是全站唯一主动查业务库的地方,以前只在守卫放行和字符串片段两层上测过,从没在真库上跑过。
本机四个容器(PG 16、MySQL 8.4、MariaDB 11、Oracle Free 23)实测,旧的 IN 列表写法在 PostgreSQL 上整数子列
对文字主键直接报 operator does not exist: character varying = integer,关系一条都核对不了。
C1 方言修正:
- IN 列表的字面量按被指向列的类型族写(key_literals):父列文字写 '12',父列数字只收整数写法的值,父列是时间、
对不上的不拼并在备注里写「两端类型不同」;子表是 CHAR(n) 时去掉补齐的尾随空格。
- 列类型改存按方言编译的完整写法(VARCHAR2(20 CHAR)、NUMBER(10, 0)、ENUM('a','b')、TIMESTAMP WITH TIME ZONE),
编译不了退回 str()。SQLAlchemy 把 Oracle 的 VARCHAR2 反射成通用 VARCHAR(容器实测),照数据字典写成 VARCHAR2。
ENUM / SET 另记 enum_values;Oracle 小写带引号的表和列记 quote_name;各索引(含主键)的首列记进
index_first_columns(下一波取值观察判断能不能对大表发窗口查询)。新探查的快照哈希会变,旧运行封存的不受影响。
- catalog._type_family 认 ENUM / SET 是文字、INTERVAL 不是数字,去掉引号里的取值再认;新增 column_family
(有 enum_values 的是文字,PostgreSQL 枚举编译出来只有类型名);is_date_column 不再把 ENUM('date') 认成日期列。
- 码值候选:ENUM / SET 不看列名直接算候选,ENUM 列定义里这次没出现的取值也写进码值(含义待填);VARCHAR2(20 CHAR)
的长度按 20 算;CHAR 码值去尾随空格;MySQL 上写明按排序规则分组、比较(可能不分大小写)。
- 统计信息估出的行数不超过整表统计上限时再跑一次有上限的计数确认,统计过期的大表不再被当成小表做整表统计。
- 日期列的最小值、最大值只看 0001-01-02 到 9999-12-31 之间的值,零日期、占位日期、PG 的 ±infinity 不计入,
照实写「另有 N 个无效日期未计入」,日期范围里带 invalid 个数(界面显示)。
- 新增取值观察用的方言方法 date_literal / day_trunc / sample_from,以及按日行数、时间窗口里的取值分布、块采样三类
查询的拼法(窗口上端截在 9999-12-31 之前,不让 infinity 多出一天)。
- 说明文字不再说「抽样」:大表看的是「按存储顺序取前 N 行」;设置项「抽样键值数」改叫「核对键值数」。
C2 验证:
- tests/test_profile_dialect_golden.py:五种方言 × 全部剖析和观察查询的完整 SQL 钉在 tests/fixtures/dialect/,
sqlglot 逐条解析、过只读守卫,再用 qualify + annotate_types 核对 IN 两边类型族一致(附旧写法的对照)。
- scripts/dialect-it.sh(不进 CI):本机起四个容器,建虚构夹具(保留字列、Oracle 小写带引号的表、CHAR 码值、
MySQL ENUM、零日期 / infinity / 占位日期、做旧的统计信息、超上限的大表、带索引的日期列),用 AgentLab 自己的
探查和剖析代码跑全部查询,断言零报错、结论和手算一致。四种库都通过;MariaDB 插入时自己更新行数估算,统计信息
做不旧,照实打印。把 IN 列表改回旧写法回跑,PG 上照样报出上面那条错误。跑完删容器、留镜像。
|
2026-10-16 10:25:28 +08:00 |
|
ThearchyHelios
|
6b3c737fb8
|
数据剖析改成逐表的后台任务:引擎改编排、剖析任务、接口、设置换新键
以前剖析是一次同步长请求,预算按整次算(max_queries 60、max_total_s 120),选 50 张表只做得完前两三张,其余整张记「查询次数用完」;不能停,关掉页面报告就没了,对业务库查了什么无从查。
- data/catalog_profile.py:检查逻辑和 _apply 并入规则原样保留,只换编排。公开的逐表入口 profile_table:先列全检查项(plan_checks,纯函数,范围的 profile_checks、建任务时列的检查项、执行用同一份;遮罩、多列、不在表结构里、指向视图的关系在这里就列成按规则跳过),第一条查询估行数(确知空表整张表跳过),逐项执行、进度回调,整张表结束写目录并和回调在同一次库操作里;停止时做完的项照常写、没做的记 cancelled 保留旧结论。_Runner 拆成整个任务一个的 SourceRunner(只读守卫、单条时限、任务级止损:连续 3 条失败、最近 10 条 7 条超时;最近 6 条 4 条超时提醒;每条查询留痕,SQL 经 normalize_sql 去掉字面量)和每张表一个的 TableBudget(用完只停这张表)。删掉同步的 profile_catalog、挑表前批量估行数(_skip_empty、PROFILE_DEFAULT_TABLES、PROFILE_PROBE_TABLES)和进程内 _RUNNING。设置换成 table_max_queries(1–200,缺省 40)、table_max_s(10–600,缺省 60),旧键 max_queries、max_total_s 启动时从库里删掉(migrate_settings,不折算:旧值按整次算,含义不同),保存时只摘掉不报错(without_legacy)。表助手的 run_query 和起草时核对有效记录条件改走单条查询入口 run_single_query,行为不变。
- data/catalog_profile_jobs.py:剖析任务的建(selected / needed / all 三种范围,排序同前:有待核实关系的在前、使用次数、表结构顺序;挑出 0 张 ProfileNothing)、排队(和同源起草按建立先后串行,waiting_for)、执行(每张表开始前重读数据源:停用或关掉剖析就停下;遮罩按最新设置)、停止、重试、启动标中断不续跑、保留最近 50 个结束的任务(某张表最近一次剖析所在的不删)、last_profile / profile_due 的查询、任务和逐表的接口形状。
- api/catalog.py:加 /profile-jobs(建、active、latest、{job_id}、tasks/{seq}、cancel、retry),登记在 /{table} 前面;删掉 POST /catalog/profile;清单每行加 last_profile、profile_due、profile_due_reason、profile_checks,顶层加 active_profile_job;单表加 last_profile;导入目录、同步起草遇到剖析任务 409 profile_busy。api/coded.py 加 profile_nothing、catalog_profile_finished;api/datasources.py 保存时摘掉旧键;main.py 启动时标中断加设置迁移,关停时停掉进行中的剖析。
- 测试:test_catalog_profile.py、test_catalog_profile_units.py、test_catalog_semantics.py 里打同步接口和旧设置键的改走任务和新键,检查逻辑的断言保留;同步接口的整次总量上限一条改成逐表次数、逐表时长两条。
|
2026-10-15 18:30:48 +08:00 |
|
ThearchyHelios
|
661f6a38d7
|
A7 剖析写进目录的说明不再写日期:以前写的是 UTC 日期(at[:10]),和界面上按本地时间显示的修改时间对不上;改为「数据剖析:…」,时间以这一项的 updated_at 为准。is_profile_note 同时认升级前带日期的「数据剖析(日期):」;same_profile_note 继续兼容旧数据:只差日期、或一段带日期一段不带的同一结论都算相同,升级后重新剖析不会给每张表升版本
|
2026-10-04 02:19:26 +08:00 |
|
ThearchyHelios
|
46c3fd3093
|
A6 扇出检查只在一对多确有其事时报错误:关系人工确认过,或数据剖析在数据上核实过子表一侧的键不唯一(关系上记 cardinality_checked,子表太大没核对的不算)才给 error;只凭外键结构推出的一对多降为 warning,说法改成「可能重复计算」,下一步写确认关联表里每个键只有一行、或先汇总再关联;人工编辑提交里带的 cardinality_checked 不作数;级别说明「结果必然有误」改为不夸大的说法;2B、F1 的测试按新规则更新:外键 + verified → warning,剖析核实过 → error,人工确认 → error
|
2026-10-04 02:19:26 +08:00 |
|
ThearchyHelios
|
d805f64195
|
数据目录 F1 一致性:日期列的判定抽成 catalog.is_date_column,数据剖析(唯一日期列提议业务日期)和 SQL 检查(按业务日期以外的时间列统计)共用,只有时刻的 TIME、整数存的时间戳两边都不算;表名匹配统一按 name_key(只把 ASCII 字母转小写),resolve_table_name 和 SQL 检查里认表名不再按 Unicode 转小写,和使用次数、影响面同一个口径;切词合并成 catalog.name_words,剖析不再另写一份;更新过时的说明(错误级检查已经上线、剖析预算的叫法跟设置界面);码值比较不分大小写保留,注释写明是照顾 MySQL 默认排序规则、宁可漏报
|
2026-10-04 01:17:29 +08:00 |
|
ThearchyHelios
|
f5e8a436f1
|
数据目录 F1-B3:计算公式在人工整份提交和模型起草两条路径上也拦下——人工提交里改动过的文字项像公式就整份不收(422,说明公式写进口径卡),模型起草出的公式项丢掉;和对话提案同一套判断。只查改动过的项、不进结构校验:库里已有的含公式的项不会挡住这张表的写入
|
2026-10-04 01:15:05 +08:00 |
|
ThearchyHelios
|
bf5bee9246
|
数据目录 F1-B2:剖析写的备注只是开头的日期变了、其余都没变时,保留旧的项、不升版本(人工确认过的关系也一样)。以前隔天重新剖析、数据没变,目录版本也加 1,发布时记下的目录版本就对不上,之后每次正式运行都误报目录有变化
|
2026-10-04 01:14:08 +08:00 |
|
ThearchyHelios
|
b078d08ffe
|
数据目录 F1-A4:码值项加「已列全」标记(complete: true),只有人工明确勾选、或剖析整表统计(没有只看前若干行)得到的码值才有;码值不在码值表中的检查只认标了它的码值表,给模型的话改为提示核对取值,不再叫它照目录里的码值改。以前经对话只补了 status=9 表示作废,之后 status = 1 就被报提醒,模型还可能把对的 SQL 改错。提案补充码值时沿用原有的标记、自己不能标;目录页的码值编辑和填写含义弹窗加「已列出全部取值」勾选,表格里标「已列全」,检查脚本跟上
|
2026-10-04 01:13:13 +08:00 |
|
ThearchyHelios
|
fd3ec43662
|
数据目录 F1-A2:在目录页去掉外键约束、命名推断、数据剖析、模型起草得出的关联关系改为驳回、保留编号,只有人工添加的才真正删除;改了两端的旧关系同样驳回。以前删掉的推断关系下次起草又加回来,关系图按表结构现推也会带回来,照样驱动 SQL 检查和助手挑表。表结构推得出的人工关系(人工改过基数的外键关系)去掉时也只驳回。编辑界面上这类关系不给「删除」只给「驳回」(保存时等同单项驳回,可撤销),检查脚本跟上
|
2026-10-04 01:07:35 +08:00 |
|
ThearchyHelios
|
0fa498ac18
|
数据目录 F1-A1:对话提案确认关联关系时不再抹掉基数和覆盖率——覆盖率是剖析测得的,一律沿用;基数没写时沿用已有的,新增的按目标表的主键或唯一约束推算,推算不了留空并在提案这一项上说明(PatchChange.note)。以前剖析测得多对一的关系经提案确认后基数变空,一对多关联后重复计算的检查静默失效
|
2026-10-04 01:03:32 +08:00 |
|