Planning Changes to Tables or Columns

When you are planning to make a backward-incompatible change, you need to proceed in a way that minimizes the impact and gives downstream stakeholders as much warning as possible. Examples of backward-incompatible changes are:

• Changing a schema (type changed, name changed)
• Changing values (data fields will no longer be populated, or will be populated differently)

You need to understand and communicate the impact before you make such a change. This is usually done in the following steps:

1. Understand the impact: understand who uses or queries this data.
2. Provide heads-up notification: notify downstream owners and users that this data is going to change, and that they need to update their assets (downstream tables or dashboards) accordingly. Provide a time window after which the change will go into effect.
3. (ideally): Understand the impact again: see if downstream users have changed their assets; how many still need to be nudged, etc.?
4. Make the actual change and follow up to make sure that it’s complete.

Stemma can help you make the change as painless as possible. Use the UI to assess the effect on downstream users and on other assets. The following sections provide help:

• Owners
• Frequent users
• Slack conversations
• Commonly used with
• Lineage
• Dashboards
• Column usage and lineage

If you are deprecating a table:

• Change the description to warn users about the impending change.
• Change the status toDeprecated.

Now warn all owners and frequent users about the change, and give them a deadline to make their adjustments.