How does dbdeux's review with context impact pull request approval?
A Git diff shows a reviewer what changed in the code. It says nothing about what the change does to the data, the schema, or everything downstream, and that is what dbdeux puts on the pull request.
A reviewer opens a pull request (PR). The SQL diff is a few lines, and it reads fine, so he approves it. A day later a dashboard shows the wrong number, or a downstream model fails to build. The change renamed a column, or switched its type, and nothing in the review showed it. The approval was a guess.
That is how most code reviews in data projects work. The reviewer is reading the text of a change, not its effect on the data.
What the diff hides
A Git diff is good at one thing: showing what changed in the code. It says nothing about what that change does to the schema, to the data in the table, or to the dozens of models and dashboards that read the changed model. The one thing a reviewer needs in order to judge a data change, its impact, is the one thing the diff does not show.
Tests catch some of this, later, and only if someone writes the right test. But in the review itself, at the moment of approval or not, the reviewer is working blind.
What a review with context shows
A review has context when the PR itself shows three things a text diff cannot:
The schema change. Which columns were added, removed, or retyped. On the PR, the reviewer should see that a model gained a margin_bucket column, or lost one, or changed a column from a number to a string, instead of finding out in production.
Whether it breaks anything. Not every schema change is equal. Adding a column is safe. Renaming one, dropping one, or changing its type can break every model and dashboard downstream. The review should indicate what is involved: adding margin_bucket is flagged safe, while a rename or a type change would be flagged as breaking, a verdict a text diff can never give on its own.
What it touches, column by column. Model-level lineage, the view that says "these models depend on that model", is useful but coarse. The question a reviewer actually has is more subtle: Which downstream columns are built from the column that changed? Column-level lineage answers exactly that, so the reviewer sees the real blast radius before merging, not after.
Why review with context is not a command-line flag
It is worth being clear about this, because the earlier articles in this series were careful to show where dbt already does the work. Slim CI, the subject of the last article, is native dbt: the capability was always dbt's, and the job was only running it on every PR without building the machinery by hand.
Review with context is a different case. state:modified+ tells a team what will be rebuild. It does not put a schema diff, a breaking-change verdict, or column-level lineage in front of the person approving the PR. None of these is a selector or a flag. They are capabilities the review did not have before. This is the pillar where "the capability is already dbt's" simply does not apply, And the most honest thing to do is to say that.
What it looks like in practice
In dbdeux these three signals appear on the PR on their own, on the same project and the same change used in the earlier articles. There is no test to pre-write and no second tool to open next to the PR. The reviewer approves with the impact in view.
The point is
The review stops being a leap of faith. Before merge, the reviewer sees the schema change, whether it breaks anything, and exactly which downstream columns it touches, instead of learning it a day later from a broken dashboard and an annoyed stakeholder. That is the review amendment from the first article in this series, which has now concluded.
BRF Consulting has been a partner of AICG, which specializes in Data Engineering, Data Integration, and is dbdeux's developer. |
About the author: Thiago Lima is an independent consultant for BRF Consulting.
BRF Consulting specializes on Data Engineering, Artificial Intelligence, Software Development, Salesforce and CRM (Customer Relationship Management). For more information about our services, email us at contact@brfconsulting.com. |
Comments