{{ message }}
Repository navigation
Commit 06723ea
fix(advisor/tidb): canonicalize BOOLEAN ↔ tinyint(1) in normalizeColumnType (Codex round-5 on batch 11)
Codex P2 round-5 correctly flagged: omniBuildColumnTypeString renders
DataType.Name verbatim ("boolean"), but TiDB/MySQL stores BOOLEAN
columns as tinyint(1) (verified via backend/plugin/schema/tidb/get_database_metadata.go:437-438
and backend/plugin/schema/mysql/get_database_metadata.go:259-261).
Empirical reproduction:
Pingcap BOOL/BOOLEAN → Tp.String() = "tinyint(1)" (canonicalized)
Pingcap TINYINT(1) → Tp.String() = "tinyint(1)" (same)
Pingcap TINYINT (bare) → Tp.String() = "tinyint(4)" (default width)
Omni BOOL/BOOLEAN → DataType{Name="BOOLEAN", Length=0}
Omni TINYINT(1) → DataType{Name="TINYINT", Length=1}
Catalog stores "tinyint(1)" for boolean columns.
Pre-fix false-positive:
catalog: "tinyint(1)"
user: ALTER TABLE t MODIFY x BOOLEAN (no-op against a boolean column)
omni-built: "boolean"
normalize: default branch → identity → "boolean"
comparison: "boolean" ≠ "tinyint(1)" → flagged as type change
Fix: add `"boolean"` and `"bool"` cases to normalizeColumnType, both
mapping to `"tinyint(1)"`. Placed in normalizeColumnType rather than
omniBuildColumnTypeString because the normalize layer is where the
existing canonicalization conventions live (integer default widths
already follow this pattern: `int` ↔ `int(11)`, `tinyint` ↔ `tinyint(4)`).
Both sides of the comparison go through normalize, so the canonicalization
is symmetric — works regardless of which side originally rendered which
form.
Codex round-5 of 5 on omniBuildColumnTypeString in this PR:
#1 BLOB/TINYBLOB/VARBINARY " BINARY" suffix → cumulative #21
#2 DECIMAL zero-scale + ZEROFILL drop → round-2 commit
#3 FLOAT/DOUBLE/REAL precision-hint drop → round-3 commit
#4 ENUM/SET value-literal drop → round-4 commit
#5 BOOLEAN ↔ tinyint(1) alias normalization → this commit
The field-by-field DataType audit (Name, Length, Scale, Unsigned,
Zerofill, Charset, Collate, EnumValues, ArrayDim, SRID) that I
identified in round-4 as the missing pre-batch discipline would NOT
have caught round-5 — this is a TYPE-NAME canonicalization concern,
not a field-rendering concern. The pre-batch discipline addition for
this class: when porting a rule that compares type-strings against
the catalog, audit normalizeColumnType for alias coverage by
cross-referencing MySQL's documented type aliases (BOOL/BOOLEAN ↔
TINYINT(1), DEC ↔ DECIMAL, REAL ↔ DOUBLE, INTEGER ↔ INT, etc.) and
backend/plugin/schema/*/get_database_metadata.go's explicit
normalization map.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>1 parent 4ea5c3e commit 06723ea
1 file changed
Lines changed: 26 additions & 5 deletions

0 commit comments