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] Allow for both custom_field_id and name if desired for passthrough column #59

Open
2 of 4 tasks
fivetran-joemarkiewicz opened this issue Jun 10, 2022 · 1 comment
Labels
type:enhancement New functionality or enhancement

Comments

@fivetran-joemarkiewicz
Copy link
Contributor

Is there an existing feature request for this?

  • I have searched the existing issues

Describe the Feature

Currently, the issue_field_history_columns variable allows for the field name to be passed through to the final models. However, as addressed within this dbt Slack thread it was understood that the name field is too mutable and changes too frequently. Additionally, there is no restrictions for Jira users to name two different fields the same 😱

As such, I want to consider a possibility for the package to allow the name of the custom fields to be passed through in addition to the id as well. The id is pretty hard to interpret for an end user (which is why we removed this feature before), but there is now a possibility for data integrity issues as the name is mutable. I would like to consider a solution where there are two variables.

  • A variable for the name of the custom field to be passed through
  • The id of the field to be passed through

This way the package will have the best of both worlds!

I would still like to keep the name version of the custom field as it is a lot easier for folks to decipher what the fields are when looking at their dbt_project.yml and for initial setup as well. However, I do believe we should include an option for folks to use id if they wanted to ensure the fields are immutable.

Describe alternatives you've considered

Currently there are no other alternatives other than the PR #58 I opened which is a working solution for this.

Please note that this PR is not the final version and just a working version of my thoughts on a solution.

Are you interested in contributing this feature?

  • Yes.
  • Yes, but I will need assistance and will schedule time during your office hours for guidance.
  • No.

Anything else?

One thing we will need to communicate is that if a user leverages the id variable, the end model will still display the name. As such, they will still need to consider a --full-refresh if that field does in fact change.

Additionally, we should consider changing the name of the variable altogether. The name is no longer descriptive of what it does since it is used in more than just the issue_field_history end model. Just a thought.

@fivetran-sheringuyen fivetran-sheringuyen added type:enhancement New functionality or enhancement and removed enhancement labels Dec 22, 2022
@kenzie-marsh
Copy link

This FR would be very helpful in our project, as we have 2 Jira fields with the same name, so are currently unable to report on either of them accurately!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type:enhancement New functionality or enhancement
Projects
None yet
Development

No branches or pull requests

3 participants