Calling macros across projects in dbt - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ Predict Output

intermediate

Output of calling a macro from another project

Given two dbt projects, project_a and project_b, where project_b defines a macro calculate_discount() that returns price * 0.9. In project_a, you call this macro using {{ project_b.calculate_discount(100) }}. What is the output?

dbt

{% macro calculate_discount(price) %}{{ price * 0.9 }}{% endmacro %}

-- In project_a model:
select {{ project_b.calculate_discount(100) }} as discounted_price

A 100

B 90.0

C SyntaxError: macro not found

D 10.0

💡 Hint

Remember that macros from other projects can be called using the project name as a prefix.

The macro calculate_discount multiplies the input price by 0.9, so calling it with 100 returns 90.0.

🧠 Conceptual

intermediate

Understanding macro namespace in dbt projects

In dbt, when calling a macro from another project, which of the following is true about the macro namespace?

A Macros must be called with the project name prefix to avoid conflicts.

B Macros from other projects are automatically imported without prefix.

C Macros cannot be called across projects in dbt.

D Macros from other projects override local macros without prefix.

💡 Hint

Think about how dbt avoids macro name collisions.

dbt requires using the project name prefix when calling macros from other projects to avoid naming conflicts.

🔧 Debug

advanced

Debugging macro call error across projects

You have a macro format_date() defined in project_x. When calling {{ project_x.format_date('2024-01-01') }} in project_y, you get an error: Runtime Error: 'project_x' is undefined. What is the most likely cause?

A Macros cannot accept string arguments across projects.

B The macro name <code>format_date</code> is misspelled in <code>project_x</code>.

C The <code>project_x</code> is not listed as a dependency in <code>project_y</code>'s <code>packages.yml</code>.

D The macro must be called without the project prefix.

💡 Hint

Check if the other project is properly included as a dependency.

If project_x is not added as a dependency in project_y, dbt cannot find its macros, causing the error.

❓ data_output

advanced

Result of macro generating SQL across projects

In project_main, you call a macro from project_utils that generates a SQL snippet to filter rows where status = 'active'. The macro is called as {{ project_utils.filter_active() }} inside a model's where clause. What is the resulting SQL snippet inserted?

dbt

{% macro filter_active() %}status = 'active'{% endmacro %}

-- Usage in project_main model:
select * from users where {{ project_utils.filter_active() }}

A 'status = active'

B WHERE status = 'active'

C status == 'active'

D status = 'active'

💡 Hint

Macros return raw SQL snippets to be inserted as-is.

The macro returns the condition status = 'active' without quotes or extra keywords, so it fits correctly in the WHERE clause.

🚀 Application

expert

Using macros across projects to standardize date formatting

You want to standardize date formatting across multiple dbt projects by defining a macro format_date(date, format) in project_common. How should you call this macro in project_sales to format the date order_date as 'YYYY-MM-DD'?

A {{ project_common.format_date(order_date, 'YYYY-MM-DD') }}

B {{ format_date(order_date, 'YYYY-MM-DD') }}

C {{ project_sales.format_date(order_date, 'YYYY-MM-DD') }}

D {{ project_common.format_date('order_date', 'YYYY-MM-DD') }}

💡 Hint

Remember to use the project prefix and pass variables correctly.

To call a macro from another project, use the project prefix and pass the variable without quotes.

Practice

1. What is the main reason to call macros across different dbt projects?

easy

A. To make the project run slower

B. To increase the size of the project

C. To reuse code and keep projects organized

D. To avoid using any dependencies

Solution

1. Step 1: Understand the purpose of macros

   Macros are reusable pieces of code that help avoid repetition.

2. Step 2: Recognize the benefit of calling macros across projects

   Calling macros across projects allows sharing code, which keeps projects clean and organized.

3. Final Answer:

   To reuse code and keep projects organized -> Option C

4. Quick Check:

   Code reuse = To reuse code and keep projects organized [OK]

Hint: Macros help reuse code across projects easily [OK]

Common Mistakes:

• Thinking macros increase project size
• Believing macros slow down the project
• Ignoring the need for dependencies

2. Which syntax correctly calls a macro named calculate_total from a project named sales_project?

easy

A. {{ sales_project.calculate_total() }}

B. {{ calculate_total() }}

C. {% sales_project.calculate_total() %}

D. {{ sales_project->calculate_total() }}

Solution

1. Step 1: Recall the correct macro call syntax

   Macros from other projects are called using {{ project_name.macro_name() }}.

2. Step 2: Match the syntax to the options

   {{ sales_project.calculate_total() }} uses the correct dot notation and double curly braces.

3. Final Answer:

   {{ sales_project.calculate_total() }} -> Option A

4. Quick Check:

   Use dot notation inside {{ }} = {{ sales_project.calculate_total() }} [OK]

Hint: Use {{ project_name.macro_name() }} to call macros [OK]

Common Mistakes:

• Using {% %} instead of {{ }} for macro calls
• Missing the project name before the macro
• Using incorrect symbols like ->

3. Given the following packages.yml snippet and macro call, what will happen?

packages:
  - package: sales_project
    version: 1.0.0

-- In a model SQL file:
SELECT {{ sales_project.calculate_discount(100) }} AS discount_amount

medium

A. The macro will run and return the discount value

B. Error because the macro call syntax is wrong

C. Error because sales_project is not added as a dependency

D. The SQL will run but ignore the macro call

Solution

1. Step 1: Check the packages.yml for dependencies

   The sales_project is listed as a dependency, so it is available.

2. Step 2: Verify the macro call syntax

   The macro is called correctly using {{ sales_project.calculate_discount(100) }}.

3. Final Answer:

   The macro will run and return the discount value -> Option A

4. Quick Check:

   Dependency + correct syntax = macro runs [OK]

Hint: Add project in packages.yml before calling macros [OK]

Common Mistakes:

• Forgetting to add dependency in packages.yml
• Using wrong macro call syntax
• Assuming macro calls run without dependencies

4. You try to call a macro from another project but get an error. Which of these is the most likely cause?

medium

A. The macro name is misspelled in the call

B. You used single curly braces instead of double

C. The macro is called without parentheses

D. The other project is not listed in packages.yml

Solution

1. Step 1: Identify common errors in cross-project macro calls

   Missing the other project in packages.yml means dbt cannot find the macro.

2. Step 2: Compare other options

   Misspelling or syntax errors cause different errors, but missing dependency is most common.

3. Final Answer:

   The other project is not listed in packages.yml -> Option D

4. Quick Check:

   Missing dependency = macro call error [OK]

Hint: Always add dependencies in packages.yml first [OK]

Common Mistakes:

• Ignoring packages.yml dependencies
• Using wrong macro call syntax
• Forgetting parentheses in macro calls

5. You want to call a macro format_date from a project utils_project inside your project. You added utils_project in packages.yml. Which is the correct way to pass a date string '2024-01-01' to the macro and use its result in a model?

hard

A. SELECT {{ utils_project.format_date(`2024-01-01`) }} AS formatted_date

B. SELECT {{ utils_project.format_date("2024-01-01") }} AS formatted_date

C. SELECT {{ utils_project.format_date(2024-01-01) }} AS formatted_date

D. SELECT {{ utils_project.format_date('2024-01-01') AS formatted_date }}

Solution

1. Step 1: Confirm dependency is added

   utils_project is added in packages.yml, so macro can be called.

2. Step 2: Check correct string passing in macro call

   Strings in Jinja macros should be double-quoted inside {{ }} to avoid syntax issues.

3. Step 3: Validate SQL syntax

   SELECT {{ utils_project.format_date("2024-01-01") }} AS formatted_date correctly uses double quotes inside the macro call and proper SQL aliasing.

4. Final Answer:

   SELECT {{ utils_project.format_date("2024-01-01") }} AS formatted_date -> Option B

5. Quick Check:

   Double quotes for strings in macro calls = SELECT {{ utils_project.format_date("2024-01-01") }} AS formatted_date [OK]

Hint: Use double quotes for string args inside {{ }} [OK]

Common Mistakes:

• Using unquoted strings causing errors
• Incorrect SQL alias syntax
• Missing quotes or wrong quote types