Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature] env_var does not work in an object under the vars section of dbt_project.yml #4314

Closed
1 task done
joseph-chan-thoughtworks opened this issue Nov 22, 2021 · 9 comments
Labels
enhancement New feature or request stale Issues that have gone stale

Comments

@joseph-chan-thoughtworks

Is there an existing issue for this?

  • I have searched the existing issues

Current Behavior

vars:
  STAGING:
    database: "{{ env_var('STAGING_DATABASE') }}"
    schema: "{{ env_var('STAGING_SCHEMA') }}"

This fails due to unexpected "{". However,

vars:
  STAGING_DATABASE: "{{ env_var('STAGING_DATABASE') }}"
  STAGING_SCHEMA: "{{ env_var('STAGING_SCHEMA') }}"
  STAGING:
    database: "{{ var('STAGING_DATABASE') }}"
    schema: "{{ var('STAGING_SCHEMA') }}"

Expected Behavior

env_var within an object should parse correctly as well.

Steps To Reproduce

  1. add STAGING_DATABASE and STAGING_SCHEMA to your environment
  2. create a dbt project and add the above code block to dbt_project.yml
  3. run dbt run or a linter for example sql_fluff

Relevant log output

.exceptions.DatabaseException: Database Error
  001003 (42000): SQL compilation error:
  syntax error line 1 at position 15 unexpected '{'.
  syntax error line 1 at position 25 unexpected '('.
  syntax error line 1 at position 46 unexpected '}'.

Environment

- OS: MacOX 11.6
- Python: 3.8
- dbt: 0.20.x

What database are you using dbt with?

snowflake

Additional Context

No response

@jtcohen6
Copy link
Contributor

jtcohen6 commented Nov 25, 2021

@joseph-chan-thoughtworks Thanks for opening!

The values of vars, defined in dbt_project.yml, aren't rendered today. They have to be defined as static values. As such, dbt doesn't resolve the env_var() or var() calls in your definitions — it just stores the whole string value, curly braces and all.

I believe this is a duplicate of #3105. We should update the docs here to make clear that vars don't support rendering.

Could I ask for a bit more context about the use case you're after? Why are you creating a var to package env var values, rather than just referencing the env vars themselves in your downstream configuration / models / etc?

I appreciate the ergonomics of being able to synthesize target or env_var values to assign vars, and avoid duplication of more verbose expressions elsewhere; but I don't think there's anything that's functionally impossible because of this limitation.

@jeremyyeo
Copy link
Contributor

jeremyyeo commented Mar 16, 2022

Hey @jtcohen6, one possible use case for this is that packages tend to use variables to control "features". Let's say we use the hubspot package in our project. The way one would disable models in that package is by setting vars that are relevant to that package:

# dbt_project.yml

vars:
  hubspot_marketing_enabled: false
  hubspot_contact_enabled: false
  hubspot_sales_enabled: true
  hubspot_company_enabled: true
...

So to override those many vars, you would have to have some super long string in your run command:

dbt run --vars {hubspot_marketing_enabled: true, hubspot_contact_enabled: true, hubspot_sales_enabled: false, hubspot_company_enabled: false, ...}

Which is less than ideal.

And as of now, the following wont work:

Standard variables

# dbt_project.yml

vars:
  hubspot_marketing_enabled: "{{ var('control_flag_a') }}"
  hubspot_contact_enabled: "{{ var('control_flag_a') }}"
  hubspot_sales_enabled: "{{ var('control_flag_b') }}"
  hubspot_company_enabled: "{{ var('control_flag_b') }}"
...
dbt run --vars '{control_flag_a: true, control_flag_b: false}'

Environment variables

# dbt_project.yml

vars:
  hubspot_marketing_enabled: "{{ env_var('control_flag_a') }}"
  hubspot_contact_enabled: "{{ env_var('control_flag_a') }}"
  hubspot_sales_enabled: "{{ env_var('control_flag_b') }}"
  hubspot_company_enabled: "{{ env_var('control_flag_b') }}"
...

@github-actions
Copy link
Contributor

This issue has been marked as Stale because it has been open for 180 days with no activity. If you would like the issue to remain open, please remove the stale label or comment on the issue, or it will be closed in 7 days.

@github-actions github-actions bot added the stale Issues that have gone stale label Sep 13, 2022
@github-actions
Copy link
Contributor

Although we are closing this issue as stale, it's not gone forever. Issues can be reopened if there is renewed community interest; add a comment to notify the maintainers.

@adam-wrobel
Copy link

I would greatly appreciate this feature to exist.

@franviera92
Copy link

I would also like this change, if I need to specify a vars per environment, how would I apply this change currently?

@dbeatty10 dbeatty10 reopened this Jun 16, 2023
@dbeatty10 dbeatty10 added enhancement New feature or request and removed bug Something isn't working triage labels Jun 16, 2023
@dbeatty10 dbeatty10 changed the title [Bug] env_var does not work in an object under the vars section of dbt_project.yml [Feature] env_var does not work in an object under the vars section of dbt_project.yml Jun 16, 2023
@dbeatty10 dbeatty10 removed the stale Issues that have gone stale label Jun 16, 2023
@timvw
Copy link

timvw commented Jun 16, 2023

I would also like this change, if I need to specify a vars per environment, how would I apply this change currently?

That's why I avoid vars (I only use them for setting environment unaware/unrelated things)

nghi-ly added a commit to dbt-labs/docs.getdbt.com that referenced this issue Jun 22, 2023
[Preview](https://deploy-preview-3554--docs-getdbt-com.netlify.app/docs/build/project-variables#defining-variables-in-dbt_projectyml)

## What are you changing in this pull request and why?

`vars` within `dbt_project.yml` does not support rendering, but it has
been requested dbt-labs/dbt-core#3105 and
dbt-labs/dbt-core#4314.

In the meantime, we want to make it clear within our docs that this
isn't supported.

See
dbt-labs/dbt-core#4314 (comment)
for context.

## 🎩 

<img width="550" alt="image"
src="https://github.com/dbt-labs/docs.getdbt.com/assets/44704949/95e6e65a-028e-4e85-8c56-c4cf12929dc7">


## Checklist
- [x] Review the [Content style
guide](https://github.com/dbt-labs/docs.getdbt.com/blob/current/contributing/content-style-guide.md)
and [About
versioning](https://github.com/dbt-labs/docs.getdbt.com/blob/current/contributing/single-sourcing-content.md#adding-a-new-version)
so my content adheres to these guidelines.
Copy link
Contributor

This issue has been marked as Stale because it has been open for 180 days with no activity. If you would like the issue to remain open, please comment on the issue or else it will be closed in 7 days.

@github-actions github-actions bot added the stale Issues that have gone stale label Feb 25, 2024
Copy link
Contributor

github-actions bot commented Mar 4, 2024

Although we are closing this issue as stale, it's not gone forever. Issues can be reopened if there is renewed community interest. Just add a comment to notify the maintainers.

@github-actions github-actions bot closed this as not planned Won't fix, can't repro, duplicate, stale Mar 4, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request stale Issues that have gone stale
Projects
None yet
Development

No branches or pull requests

7 participants