-
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
Direct child model selector #2052
Comments
Hey @bobzoller - this is a cool idea - thanks for opening this issue. We had a similar open issue over here, but it's been stale for a pretty long time: #1548. I just closed that one in favor of this one. I think a good design could be to support an integer before or after the
This integer would define the number of edges away from the specified model that dbt should traverse when selecting models to run. In this design, the number
You also noted:
I don't think my proposed syntax would address this use case. It could be a good idea to implement a workflow like this using both
The I feel pretty good about the |
Interesting…. I’m on the same page as you, Drew. I like Is it just the
So then |
I think you could use the |
Cool, I just prioritized this for the 0.17.0 (Octavius Catto) release. Let's target the syntax:
Example usage:
One interesting thing to consider: there might be multiple paths from a resource to its parents/children. Consider:
Here, the selector |
Describe the feature
Akin to the CSS Child combinator, I'd like to be able to run a given model and its direct children only.
Describe alternatives you've considered
Writing a script to consume the dbt graph and output a list of models equivalent to this feature.
Who will this benefit?
I believe this would primarily be useful in a CI environment and could significantly decrease cycle time by trading off a bit of risk. I surmise that if a given model changes, the most likely breakage will be in direct children, with odds decreasing significantly every generation after that. Personally, I'm willing to accept the risk of an Nth-level descendant breaking in return for much faster cycle times.
The caveat is you'd probably want this in addition to the ancestor side behavior of
@
--- eg I want to build direct children and all ancestors of my model and its direct children.The text was updated successfully, but these errors were encountered: