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] Improvements to source properties handling #10875

Open
3 tasks done
geo-martino opened this issue Oct 17, 2024 · 0 comments
Open
3 tasks done

[Feature] Improvements to source properties handling #10875

geo-martino opened this issue Oct 17, 2024 · 0 comments
Labels
enhancement New feature or request triage

Comments

@geo-martino
Copy link

geo-martino commented Oct 17, 2024

Is this your first time submitting a feature request?

  • I have read the expectations for open source contributors
  • I have searched the existing issues, and I could not find an existing issue for this feature
  • I am requesting a straightforward extension of existing dbt functionality, rather than a Big Idea better suited to a discussion

Describe the feature

We have a use case for dynamic assignment of database names for models which select a database name based on the currently authenticated user to allow for usage of developer-specific data sets during development. While we have been able to implement a custom generate_database_name macro for this functionality on models, we cannot apply this same logic on sources as dbt does not support using the generate_X_name macros for dynamic assignment of either database or schema properties for sources.

For context, we currently use logic similar to below to assign database names within sources properties files.

sources:
  - name: source_x
    database: "\
      reporting_
      {%- if target.name == 'dev' -%}
        {{ env_var('DBT_USER') }}
      {%- else -%}
        {{ target.name }}
      {%- endif -%}
      "

While this functionally works, we have to copy and paste this code for every single source property file in our project to reuse this logic for each source. This exact same logic is contained within our generate_database_name macro so it would be useful to be able to reuse that and not violate DRY for every new source.

I therefore suggest one of the following approaches to bring source configuration more in-line with model configuration to allow for this functionality with reference to the above example on how this would improve it.

  • Have sources properties use the generate_X_name macros automatically. e.g.
sources:
  - name: source_x
    database: "reporting"  # This would then use the `generate_database_name` macro to use the same logic as above
  • Allow usage of generate_X_name macros within source properties files to allow us to unify handling of these properties for both sources and models.
sources:
  - name: source_x
    database: "{{ generate_database_name('reporting') }}"
  • If this is not possible due to design choices, bring parity of source properties with other resource types to allow for definitions at the project file level to pass down to all sources within a resource path as is possible with models. This will at least allow us to define the logic for sources once at the project file level.
sources:
  project_name:
    resource_name:
      +enabled: true
      +database: "\
          reporting_
          {%- if target.name == 'dev' -%}
            {{ env_var('DBT_USER') }}
          {%- else -%}
            {{ target.name }}
          {%- endif -%}
          "

Describe alternatives you've considered

Manually copying and pasting database jinja templates across all source properties which violates DRY.

Who will this benefit?

Anyone who uses dynamic database or schema assignment for sources in a similar way to models. Specifically this will benefit users who need developer specific data environment handling for sources.

Are you interested in contributing this feature?

Yes

Anything else?

I am aware there are stale discussions for all of the suggestions above as described here and here.

These discussions are stale and closed so I am consolidating these here in an effort to unify discussion on this issue.

@geo-martino geo-martino added enhancement New feature or request triage labels Oct 17, 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 triage
Projects
None yet
Development

No branches or pull requests

1 participant