Built-in Jinja context variables in dbt - Step-by-Step Execution

Concept Flow - Built-in Jinja context variables

Start dbt model rendering

↓

Load built-in Jinja context variables

↓

Use variables in Jinja template

↓

Render SQL with variable values

↓

Execute rendered SQL in database

↓

Return query results

dbt loads built-in Jinja context variables, uses them to render SQL templates, then runs the SQL to get results.

Execution Sample

dbt

{% set model_name = this.name %}
SELECT * FROM {{ ref('my_table') }}
WHERE model = '{{ model_name }}'

This code uses the built-in variable 'this.name' to get the current model's name and uses 'ref' to reference another model.

Execution Table

Step	Action	Variable/Function	Value/Result	Notes
1	Load built-in variable 'this'	this.name	'my_model'	Current model name is 'my_model'
2	Call function 'ref' with argument 'my_table'	ref('my_table')	'schema.my_table'	Resolves to full table name
3	Set variable 'model_name'	model_name	'my_model'	Stores current model name
4	Render SQL template	SQL	SELECT * FROM schema.my_table WHERE model = 'my_model'	Variables replaced with values
5	Execute SQL in database	Query result	[rows returned]	Runs the rendered SQL
6	End			Execution complete

💡 All built-in variables used and SQL rendered; query executed successfully.

Variable Tracker

Variable	Start	After Step 1	After Step 3	Final
this.name	undefined	'my_model'	'my_model'	'my_model'
model_name	undefined	undefined	'my_model'	'my_model'
ref('my_table')	undefined	undefined	undefined	'schema.my_table'

Key Moments - 3 Insights

Why does 'this.name' have the value 'my_model'?

'this' is a built-in Jinja variable in dbt that represents the current model being rendered. In the execution_table step 1, 'this.name' is set to 'my_model', the model's name.

What does the 'ref' function do in the template?

'ref' is a built-in dbt function that returns the full database identifier for a referenced model or table. In step 2, 'ref('my_table')' resolves to 'schema.my_table'.

How are variables replaced in the SQL template?

In step 4, the Jinja template engine replaces variables like '{{ model_name }}' and '{{ ref('my_table') }}' with their actual values to produce executable SQL.

Visual Quiz - 3 Questions

Look at the execution_table at step 1, what is the value of 'this.name'?

A 'my_model'

B 'my_table'

C undefined

D 'schema.my_table'

💡 Hint

Check the 'Value/Result' column in step 1 of the execution_table.

At which step does the SQL template get fully rendered with variable values?

A Step 2

B Step 3

C Step 4

D Step 5

💡 Hint

Look for the step where the 'SQL' variable shows the final query string.

If 'this.name' was 'sales_model' instead of 'my_model', how would the rendered SQL change at step 4?

A The ref function would return a different table name.

B The WHERE clause would use 'sales_model' instead of 'my_model'.

C The SQL would not change.

D The query would fail to execute.

💡 Hint

Check how 'model_name' is set from 'this.name' and used in the SQL in step 4.

Concept Snapshot

Built-in Jinja context variables in dbt provide info like current model (this.name).
Use {{ this.name }} or functions like {{ ref('model') }} inside templates.
Variables are replaced during rendering to produce executable SQL.
This helps write dynamic, reusable SQL models in dbt.

Full Transcript

In dbt, built-in Jinja context variables like 'this.name' give you info about the current model. The 'ref' function helps reference other models or tables. When dbt runs, it loads these variables, replaces them in your SQL templates, and then executes the final SQL. For example, 'this.name' might be 'my_model', and 'ref('my_table')' resolves to 'schema.my_table'. The template uses these to build the final query. This process lets you write flexible SQL that adapts to your project structure.