-
Notifications
You must be signed in to change notification settings - Fork 8
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
possibility to use templated properties to apply by default on file update #38
base: main
Are you sure you want to change the base?
possibility to use templated properties to apply by default on file update #38
Conversation
ee9a6cb
to
de4e935
Compare
de4e935
to
25ef8c5
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for your PR!
And thanks also for the context you already provided. I added a few initial comments/questions so that I can further develop my understanding of how this feature may be used.
if the key isn't present, it will break what's in dbt_invoke/properties.py Co-authored-by: Robert Astel <[email protected]>
|
||
|
||
``` | ||
model: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I might be nitpicking a bit here, but I think we should change model
, seed
, snapshot
, and analysis
to their plural versions; models
, seeds
, snapshots
, and analyses
so that dbt_invoke_template.yml
matches the convention used in property files. Thoughts?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree with you! I think it's better to align to the used convention, I'll update properties.py
to use plural versions instead.
:return: None | ||
""" | ||
for key in template: | ||
if key not in property_dict: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What if the key
is already in the property_dict
, but we had altered dbt_invoke_template.yml
between the previous run and the current run?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We would keep the value already in the file – else I think it could lead to frustrating behaviors, where dbt-invoke overwrites things.
In my opinion, The template should only add new lines, and not update any existing ones, if that makes sense!
Given that this feature is totally new to dbt-invoke, we are going to need to add some tests, most likely to the A few test scenarios that immediately come to mind and that we should ensure work (both for the custom default resource properties and custom default column properties) are:
Were there any interesting scenarios or issues you noticed during your testing or any other scenarios you can think of that should be tested? Something else I am pondering: What happens if the |
Co-authored-by: Robert Astel <[email protected]>
hey, first of all, thanks for building this package, it's been a pleasure using it!
Our team recently started to use what's in the
meta
field, most notably to set themeta.owner
property:In this case,
@data-team
is our default, which we sometimes replace with an individual owner, eg.@david
, if the data model is very particular. This default value, we want it on every single data models that we create, and it was a little tedious to update all newly created.yml
file with the property.This PR adds an optional
dbt_invoke_template.yml
that will add default properties to the files updated by dbt-invoke.What changes:
dbt_invoke_template.yml
in_util.py
,_structure_property_file_dict
to apply the template's default properties.I've also updated the
README.md
file so you can better understand how this works, and I've tested this by updating my local dbt-invoke package.(feel free to edit anything on this; I'd love to have this functionality, so I'm saving the frustration of manually adding
meta.owner
)