Closed curious-bryan closed 3 years ago
hey @curious-bryan -- just realized the "minimum" solution here already somewhat exists. the intermediate model int_jira__issue_multiselect_history
contains the issue_id, field_id (which is the version_id), and updated_at. you could limit this to just version history with the following query
select *
from {{ ref('int_jira__issue_multiselect_history') }}
where field_id = 'versions'
or field_id = 'fixVersions'
which you could then join with the version table to get those extra columns, similar to how we do here
is this sufficient/does this work for you? i will note that int_jira__issue_multiselect_history
is materialized as ephemeral by default, so you may want to materialize that (or perhaps just the above query ^) as a table or view
Yep. You're right @fivetran-jamie!
great! so i'll close this since that works for ya 😄
As a data modeler, I would like a model of version history where each row describes when a version field was added to or updated for an issue, so that I could match match issues to version history.
At a minimum, a lookup table of issue id, version id, and updated_at fields would be super helpful. At a maximum, these three fields plus the remaining fields on the version table could be added.
Are you a Fivetran customer? We are a very happy Fivetran customer 😁
Is your feature request related to a problem? Please describe. This feature request would help create version history of issues.
Please indicate the level of urgency and business impact of this request This feature request would be a nice-to-have for us.
Are you interested in contributing to this package?