-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
Jinja context variable for selected resources #3471
Comments
Is there any sort of workaround available for something like this right now? Not a blocker at the moment, but would make deployment logic in my use case much terser and more intuitive. My use caseI'm using a custom However I'm trying to make it so that nodes that are outside the selection for rebuilding are ref'd from their un-suffixed schema name rather than the schema with temp suffix (in which they don't exist). Currently, because my main project is split into three (root project → source project 1 & source project 2), and the only selections I currently do in my build process are at the package level (i.e. either source project1 or source project 2 or root project), right now I just check whether |
Hi! Would it be ok for me to contribute to this issue? There are a few occasions where I wished I had this information in the Jinja context. From what I see we would need to add a I have not thought about tests so far but feel free to mention where would be the best place to add tests around the feature. |
@b-per I'm all for you taking a crack at it. The broad overview you've got sounds about right; my instinct would be to retrieve the resources (list of We'll want to very clearly document that, just as with |
After having given a further look, it doesn't look as straightforward as I thought it would be 😄 .
class ProviderContext(ManifestContext):
# subclasses are MacroContext, ModelContext, TestContext
def __init__(
self,
model,
config: RuntimeConfig,
manifest: Manifest,
provider: Provider,
context_config: Optional[ContextConfig],
) -> None: Should the approach be to import the |
Not surprised it's a bit tricky :)
This one feels like the better approach. I'm not sure which object it should live on, or the extent to which it would require rewiring in our provider. Someone from the Language pr Execution team might be able to provide clearer guidance (since this functionality really spans the two). |
Very cool! @b-per Any chance I could ask you to open an issue in https://github.com/dbt-labs/docs.getdbt.com to get this documented for v1.1? |
No worries, I'll create the issue and draft a PR |
@b-per sorry to bother, but I need some help. I am trying to implement the case @vergenzt talked about, but all I get is an empty list with selected_resources. I am using dbt 1.1.0. When I ref this variable inside a model like
it compiles to
but when I use it inside a macro like
all I get is an empty list in the logs. Is there something I need to initialize first? |
Aha - unfortunately I think |
That is a bummer. @vergenzt, did you find any work-around? right now i have ~50 teams in analytics, and for every team to have all the 300 tables is time, storage and compute consuming. The ability to pass 2 schemas would be much helpful, one for the models being run, and one for the rest. The first schema would be dev or qa, and the second the prd one. Each team would build only its models, and take the prd version of the other teams models. |
Describe the feature
A Jinja context variable that includes the list of resources (by
unique_id
) selected in the current invocation:This would have similar caveats to
graph
andexecute
, because it wouldn't be populated at parse time, only at compile/execute/runtime.Bonus points if it includes DAG information, i.e. the order in which resources will be queued for execution.
Use cases:
on-run-start
hook that wants to know all resources about to execute. This is available in theon-run-end
context, in the form of theResults
object.audit_helper.compare_relations()
for each resource selected/built by a CI job, to ensure no regressions, by looping overselected_resources
in arun-operation
(Automating Non Regression Test : How to get a ref() to the deferred version of the selected model ? #2740)Results
today in anon-run-end
hook?post-hook
on each model?Describe alternatives you've considered
Adding a property to manifest nodes:
selected: true|false
. Then users would access the samegraph
context variable and use that property. I understand that some users already do something similar, e.g. inspect thetags
on each node, to emulate selection criteria. We could also considerselection_criteria
, detailing why a given node has been selected. This could be included in thelist
output and a helpful tool for visualizing selection groupings.Make the selection criteria directly available, via
flags.args.models
andflags.args.exclude
: Add a "full run" indicator to Jinja context #2253 (comment)Additional context
Further down the road:
run-operation
task should accept--select
and--selector
Who will this benefit?
This comes up in a surprising number of more-complex use cases.
The text was updated successfully, but these errors were encountered: