SchemaQuench sometimes detects phantom changes — objects that have not actually changed semantically but appear different on each quench because the database engine reformats stored expressions on disk. The engine drops and recreates the object on every deployment, which erodes user trust and clutters deployment logs with churn that is not really there.
Concrete cases
Expression comparison normalization (cross-platform). Database engines reformat expressions when storing them. The source-of-truth .json definition says one thing; the engine reports something equivalent but syntactically different. Affected surfaces:
- Check constraints
- Default value expressions
- Computed / generated columns
- Index filter predicates
- View definitions
- Exclude constraints (PostgreSQL)
Proposed direction: an expression mapping table in a SchemaSmith tracking schema, keyed by hash, storing original-vs-deployed pairs. When the deployed form matches a known-equivalent entry, treat as unchanged.
Data type synonym detection (SQL Server). SQL Server treats rowversion / timestamp and sysname / nvarchar(128) as aliases at the catalog level, but reports them differently depending on context. The result is false column changes on every quench for tables using these types.
Impact
Users see drops and recreations they did not ask for, deployment times grow with table size for no real change, and deployment summary reports become noisy enough that real changes get lost in the noise. Affects all platforms to different degrees.
Why it matters
The whole value proposition of declarative schema management is "we converge to the declared state, and we do not touch anything that is already correct." Phantom changes break that contract. This is core trust-building work, not a cosmetic fix.
Scope
Cross-platform — SQL Server, PostgreSQL, MySQL. Each platform has its own list of expression surfaces that need normalization, but the underlying mechanism (canonical-form tracking + equivalence detection) is the same.
SchemaQuench sometimes detects phantom changes — objects that have not actually changed semantically but appear different on each quench because the database engine reformats stored expressions on disk. The engine drops and recreates the object on every deployment, which erodes user trust and clutters deployment logs with churn that is not really there.
Concrete cases
Expression comparison normalization (cross-platform). Database engines reformat expressions when storing them. The source-of-truth
.jsondefinition says one thing; the engine reports something equivalent but syntactically different. Affected surfaces:Proposed direction: an expression mapping table in a SchemaSmith tracking schema, keyed by hash, storing original-vs-deployed pairs. When the deployed form matches a known-equivalent entry, treat as unchanged.
Data type synonym detection (SQL Server). SQL Server treats
rowversion/timestampandsysname/nvarchar(128)as aliases at the catalog level, but reports them differently depending on context. The result is false column changes on every quench for tables using these types.Impact
Users see drops and recreations they did not ask for, deployment times grow with table size for no real change, and deployment summary reports become noisy enough that real changes get lost in the noise. Affects all platforms to different degrees.
Why it matters
The whole value proposition of declarative schema management is "we converge to the declared state, and we do not touch anything that is already correct." Phantom changes break that contract. This is core trust-building work, not a cosmetic fix.
Scope
Cross-platform — SQL Server, PostgreSQL, MySQL. Each platform has its own list of expression surfaces that need normalization, but the underlying mechanism (canonical-form tracking + equivalence detection) is the same.