-
Notifications
You must be signed in to change notification settings - Fork 943
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
dbt clone command #3742
dbt clone command #3742
Conversation
✅ Deploy Preview for docs-getdbt-com ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
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.
Hey @graciegoheen just two tiny link fixes to fix your staging preview. We use the document root which starts with /docs or /reference or /guides.
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.
nice solid start!!
I'd also like to see something in the docs on deferral: when/why would I use deferral versus cloning? Where are there two separate approaches to achieving the same end? (see internal notion thread)
Co-authored-by: Leona B. Campbell <[email protected]>
Co-authored-by: Leona B. Campbell <[email protected]>
Co-authored-by: Jeremy Cohen <[email protected]>
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.
Great start, thanks for taking this on @graciegoheen!
- Otherwise, dbt will create a simple pointer view (`select * from` the other object) | ||
|
||
Note: | ||
- The state to clone from is based on the location of nodes in the manifest provided to `--state`. |
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.
Something else to note here is that you cannot use the same target directory for both the source and target due to <placeholder>
.
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.
Will it literally not allow the target and source to be the same? Or would it yield surprising results?
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.
How is something like this typically called out in the docs @runleonarun
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.
@graciegoheen I would add this tidbit as a sentence in the very first paragraph. Maybe by rephrasing as what you should do instead of what you shouldn't, for example:
The dbt clone command clones selected nodes from the specified state to the target schema(s). You must always use different directories for source and target otherwise you will get an error message/overwrite the source. This command makes use of the clone materialization:
(hopefully you just get an error @aranke??)
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.
You get a very weird error that source and target states are the same, and so it's a no-op.
I ran into this during local development, so think this warning needs to be surfaced loudly.
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.
Sounds like we want a dbt-core
follow-on issue?
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.
^ yes and add callout to the docs? or yes then we don't need this callout?
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'd say "yes, and" — then when the issue is closed, we can remove the callout from the docs
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.
docs are updated - @dbeatty10 or @aranke are one of y'all able to open up a core issue to improve the error message?
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.
@graciegoheen I just now opened a minimal issue here: dbt-labs/dbt-core#8160
… with `dbt clone`
@jtcohen6 were you imagining this callout be added to the defer docs, or to the clone docs, or to both? or a new page altogether? |
How about this:
|
- You may want to specify a higher number of [threads](/docs/running-a-dbt-project/using-threads) to decrease execution time since individual clone statements are independent of one another. | ||
|
||
The `clone` command is useful for: | ||
- blue/green continuous deployment |
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.
would it be helpful to link to this so there's context? is that the right link?
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.
yes, good call! that's a fairly old post at this point, but until we have a newer one, it's good to provide some definition/context
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.
How do we feel about this being a snowflake-specific article? I think blue/green continuous blue/green deployment will be different depending on the warehouse being used (zero copy cloning vs. pointer views)
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.
Even better point. Blue/green is really only enabled by table clones. There's also hackery cleverness in that post around overriding ref
so that when the schemas get swapped, the views stay pointed to the same database.
Maybe better to skip it for now, and just say something like:
- blue/green continuous deployment (on data warehouses that support cloning tables)
Or remove the bullet entirely, until we have a more up-to-date and thorough dev blog article that we could link to
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.
Just updated - let me know what you think
To-do for @dbeatty10 and I: link to blog post highlighting differences when that's ready |
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.
One small comment (I changed my mind about the source/target mismatch error) -- then this lgtm!
For example, by creating actual data warehouse objects, `dbt clone` allows you to test out your code changes on downstream dependencies _outside of dbt_ (such as a BI tool). | ||
|
||
As another example, you could `clone` your modified incremental models as the first step of your dbt Cloud CI job to prevent costly `full-refresh` builds for warehouses that support zero-copy cloning. |
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.
nice!
What are you changing in this pull request and why?
Add docs for new
dbt clone
commandCloses #3607
Outstanding:
Previews
Checklist
website/sidebars.js