search

fivetran / dbt_jira

Data models for Fivetran's Jira connector built using dbt.
https://fivetran.github.io/dbt_jira/
Apache License 2.0
8 stars 15 forks source link

[Feature] Allow for both custom_field_id and name if desired for passthrough column #59

Open fivetran-joemarkiewicz opened 2 years ago

fivetran-joemarkiewicz commented 2 years ago

Is there an existing feature request for this?

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.

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?

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.

kenzie-marsh commented 1 year ago

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!