 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
|
d3bd80211a
|
数据目录闭环第一步（后端 A）复核修正：没收下的有效记录条件不算失败，在起草任务逐表的 log 里记一句，接口看得到（以前只进服务端日志）——没通过校验的写原因（「有效记录条件里不能有子查询，模型提议的这一条没有收下：……」），剖析核对排除 0% 或 100% 的写数到了多少行；只在请模型写表级的项的那段里记，一张表最多 10 句。CatalogDraftTask 加 log 列（存量任务回填 NULL，接口给空列表）
|
2026-10-14 10:00:10 +08:00 |
|
|
ThearchyHelios
|
7383877ee7
|
数据目录闭环第一步（后端 A）复核修正：模型提议的有效记录条件存整理过的写法——原文照旧（NOT IN、IS NOT NULL 不被改写），只把列换成表结构里的真名、不带表名、按数据源的方言要加引号的加引号，剖析核对的就是存下的这一条。以前存的是模型的原文，核对时却按真名加了引号：PostgreSQL 上混合大小写的列（"OrderStatus"）存成 orderstatus <> 'X'，一跑就报列不存在，SQL 检查还会让模型照抄。列名先照原样对表结构，只差大小写的几列写不清是哪一列的不收；加了引号超过 500 字的不收（写进去会让整张表写入失败）；不合规的说法用界面上的叫法「有效记录条件」
|
2026-10-14 09:59:52 +08:00 |
|
|
ThearchyHelios
|
9c30bf0307
|
数据目录闭环第一步（后端 A）复核修正：起草提示里「已确认的目录项」不再带遮罩列的码值，人工确认过的也不给（码值就是这一列的取值），开没开剖析都一样；这一列别的确认过的项照给。和新加的码值背景、表助手的背景、导入目录的口径一致
|
2026-10-14 09:59:35 +08:00 |
|
|
ThearchyHelios
|
4647fc9ff3
|
数据目录闭环第一步（后端 A）：防错事实的提议——起草时提议有效行过滤和去重规则
- 提示词：表级的项多要两项，valid_filter（有效行过滤，condition 写一段 SQL 条件、只用这张表的列，函数只用 UPPER、LOWER、TRIM、COALESCE）和 dedup（去重规则，rule 写一句话），各附一句 reason；写清只在表结构、注释、码值能看出来时才写，拿不准、没有就不写；业务日期照旧。结构化输出的约定、纯文本那条路的格式说明、只写表级的项那一行都带上这两项
- catalog._from_model：两项记模型起草、推断，依据写进 note（「依据：……」）；有效行过滤按数据源的方言解析（sqlcheck.parse_valid_filter），不过就丢掉、日志记一条，不算这张表失败；只写了一段文字的也认
- 起草引擎：表级那段写完核对有效行过滤。开了数据剖析的源经剖析的只读守卫数排除比例（catalog_profile.check_valid_filter），排除 0% 或 100% 的不收，收下的 note 写上「剖析核对：排除 3.2% 的行（共 12,345 行）」；没开剖析、连不上的照收，写明没有核对的原因；目录里人工确认、驳回过的不再查库
- 开了数据剖析的源：目录里记下的码值（剖析取过的取值和已知含义）交给模型做背景，要写表级的项的给全部列的、只写几列的给这几列的，遮罩的列、驳回的码值不给，已确认的不重复
- 测试核一遍 SQL 检查的规矩：起草来的有效行过滤是推断，漏了它只是提示；人工确认以后才是警告，驳回以后不报
|
2026-10-14 08:32:44 +08:00 |
|
|
ThearchyHelios
|
447c66649c
|
数据目录闭环第一步（后端 A）：有效行过滤的校验和剖析核对
- sqlcheck.parse_valid_filter / valid_filter_problem：按数据源的方言用 sqlglot 把有效行过滤解析成一个条件，只能引用这张表的列（不带表名或带这张表的表名，不分大小写），不能有子查询、聚合、窗口函数、分号、注释、模板占位、参数占位、算术，只允许比较、IN（值的列表）、BETWEEN、LIKE、IS NULL、AND / OR / NOT 和 UPPER / LOWER / TRIM / COALESCE，不超过 500 字，至少用到一列；不认识的数据源类型不收
- sqlcheck.render_valid_filter：把条件按方言重新写出来，列换成表结构里的真名、按剖析查询的规矩加引号，拼进核对查询用
- catalog_profile.check_valid_filter：开了数据剖析的源经剖析的只读守卫（guard.check(readonly=True)、单条时限、查询次数上限）发一条查询，只取条件里的列、先取前 max(抽样键值数, 整表统计行数上限) 行，数出总行数和被排除的行数；排除 0% 或 100% 的不收，收下的写「剖析核对：排除 3.2% 的行（共 12,345 行）」，只数了前若干行的写明按前几行统计；没开剖析、数据源停用、条件里有遮罩的列、视图、取值拼不进查询、查询失败或超时照收，写明没有核对的原因
|
2026-10-14 08:30:14 +08:00 |
|