Skip to content

Change Classification

Change Classification examines each modified model and categorizes the change into one of three types:

  • Additive changes
  • Column changes
  • Model-wide changes

Without classification, you have to assume that any change to a model's SQL affects every downstream model. In practice, changes differ in impact: a formatting adjustment or a new column shouldn't disrupt downstream dependencies, while a new filter condition can change every downstream result. Change Classification tells you whether a change affects downstream models and, if so, to what extent.

Usage

Use the Impact Radius view to analyze changed models and see their impacted downstream models.

Categories of change

Additive change

No downstream models are affected. Common cases include adding a new column, adding comments, or reformatting SQL without altering logic.

Example: Adding a new column

Adding a new column such as status doesn't affect downstream models that don't reference it.

select
    user_id,
    user_name,
++  status,
from
    {{ ref("orders") }}

Column change

Only downstream models that reference the changed columns are affected. Common cases include removing, renaming, or redefining a column.

Example: Removing a column

select
    user_id,
--  status,
    order_date,
from
    {{ ref("orders") }}

Example: Renaming a column

select
    user_id,
--  status
++  order_status
from
    {{ ref("orders") }}

Example: Redefining a column 

select
    user_id,
--  discount
++  coalesce(discount, 0) as discount
from
    {{ ref("orders") }}

Model-wide change

All downstream models are affected. Common cases include adding a filter condition or adding a GROUP BY column.

Example: Adding a filter condition

This may reduce the number of rows, affecting all downstream logic that depends on the original row set.

select
    user_id,
    order_date
from
    {{ ref("orders") }}
++ where status = 'completed'

Example: Adding a GROUP BY column

This changes the granularity of the result set, which affects every dependent model.

select
    user_id,
++  order_date,
    count(*) as total_orders
from
    {{ ref("orders") }}
-- group by user_id
++ group by user_id, order_date

Limitations

Change Classification is intentionally conservative to prioritize safety. As a result, a modified model may be classified as a model-wide change when it is actually an additive or column change. Common cases include:

  1. Logically equivalent rewrites, such as changing a + b to b + a.
  2. Adding a LEFT JOIN and selecting columns from the joined table. This pattern is often used to enrich a model with dimension data without affecting existing downstream models.
  3. Modified Python models and seeds, which are always treated as model-wide changes.

When to Use

  • Determine which downstream models need validation after a change
  • Prioritize review effort based on impact severity
  • Understand whether a refactor affects dependent models
  • Assess risk before merging model changes

Technology

Change Classification uses the SQL parsing and AST diff capabilities of SQLGlot to compare the semantic trees of the base and current SQL.