Skip to content

Commit

Permalink
add as snippet
Browse files Browse the repository at this point in the history
  • Loading branch information
mirnawong1 committed Aug 6, 2024
1 parent 795013f commit 4273d57
Show file tree
Hide file tree
Showing 5 changed files with 28 additions and 37 deletions.
Original file line number Diff line number Diff line change
Expand Up @@ -20,8 +20,12 @@ Is dbt Mesh a good fit in this scenario? Absolutely! There is no other way to sh

### Adoption challenges

- Onboarding hundreds of people and dozens of projects is full of friction! The challenges of a scaled, global organization are not to be underestimated. To start the migration, prioritize teams that have strong dbt familiarity and fundamentals. dbt Mesh is an advancement of core dbt deployments, so these teams are likely to have a smoother transition. Additionally, prioritize teams that manage strategic data assets that need to be shared widely. This ensures that dbt Mesh will help your teams deliver concrete value quickly.
- Bi-directional project dependencies -- currently, projects in dbt Mesh are treated like dbt resources in that they cannot depend on each other. In reality, domain teams likely need the ability to have “chatty” APIs; otherwise, they need to split projects beyond the 1:1 mapping with team boundaries. While this constraint exists today, we're working to remove this point of friction. More information about this will be provided in the near future!
- Onboarding hundreds of people and dozens of projects is full of friction! The challenges of a scaled, global organization are not to be underestimated. To start the migration, prioritize teams that have strong dbt familiarity and fundamentals. dbt Mesh is an advancement of core dbt deployments, so these teams are likely to have a smoother transition.

Additionally, prioritize teams that manage strategic data assets that need to be shared widely. This ensures that dbt Mesh will help your teams deliver concrete value quickly.
- Bi-directional project dependencies -- currently, projects in dbt Mesh are treated like dbt resources in that they cannot depend on each other. However, many teams may want to be able to share data assets back and forth between teams.

We've added support for [enabling bidirectional dependencies](/best-practices/how-we-mesh/mesh-3-structures#cycle-detection) across projects. <Lifecycle status="beta"/>

If this sounds like your organization, dbt Mesh is the architecture you should pursue. ✅

Expand Down
16 changes: 3 additions & 13 deletions website/docs/best-practices/how-we-mesh/mesh-3-structures.md
Original file line number Diff line number Diff line change
Expand Up @@ -66,22 +66,12 @@ Since the launch of dbt Mesh, the most common pattern we've seen is one where pr

Users may need to contribute models across multiple projects and this is fine. There will be some friction doing this, versus a single repo, but this is _useful_ friction, especially if upstreaming a change from a “spoke” to a “hub.” This should be treated like making an API change, one that the other team will be living with for some time to come. You should be concerned if your teammates find they need to make a coordinated change across multiple projects very frequently (every week), or as a key prerequisite for ~20%+ of their work.

### Cycle detection
### Cycle detection <Lifecycle status="beta"/>

Currently, the default behavior for "project" dependencies enforces that these relationships only go in one direction, meaning that the `jaffle_finance` project could not add a new model that depends, on any public models produced by the `jaffle_marketing` project. dbt will check for cycles across projects and raise errors if any are detected.
import CycleDetection from '/snippets/_mesh-cycle-detection.md';

However, many teams may want to be able to share data assets back and forth between teams. _We've added support for enabling bidirectional dependencies across projects, currently in beta_.
<CycleDetection />

To enable this in your account, set the environment variable `DBT_CLOUD_PROJECT_CYCLES_ALLOWED` to `TRUE` in all your dbt Cloud environments. This allows you to create bidirectional dependencies between projects, so long as the new dependency does not introduce any node-level cycles.

When setting up projects that depend on each other, it's important to do so in a stepwise fashion. Each project must run and produce public models before the original producer project can take a dependency on the original consumer project. For example, the order of operations would be as follows for a simple two-project setup:

1. The `project_a` project runs in a deployment environment and produces public models.
2. The `project_b` project adds `project_a` as a dependency.
3. The `project_b` project runs in a deployment environment and produces public models.
4. The `project_a` project adds `project_b` as a dependency.

If you enable this feature and experience any issues, please reach out to dbt Cloud support.

### Tips and tricks

Expand Down
12 changes: 2 additions & 10 deletions website/docs/best-practices/how-we-mesh/mesh-5-faqs.md
Original file line number Diff line number Diff line change
Expand Up @@ -78,18 +78,10 @@ dbt Mesh also enhances the interoperability and reusability of data across diffe

<detailsToggle alt_header="Can dbt Mesh handle cyclic dependencies between projects?">

Currently, the default behavior for "project" dependencies enforces that these relationships only go in one direction, meaning that the `jaffle_finance` project could not add a new model that depends, on any public models produced by the `jaffle_marketing` project. dbt will check for cycles across projects and raise errors if any are detected.
import CycleDetection from '/snippets/_mesh-cycle-detection.md';

However, many teams may want to be able to share data assets back and forth between teams. **We've added support for enabling bidirectional dependencies across projects, currently in beta**. To enable this in your account, simply set the environment variable `DBT_CLOUD_PROJECT_CYCLES_ALLOWED` to `TRUE` in all yur dbt Cloud environments. This will allow you to create bidirectional dependencies between projects, so long as there are not any node-level cycles introduced by the new dependency.
<CycleDetection />

When setting up projects that depend on each other, it's important to do so in a stepwise fashion. Each project must run and produce public models before the original producer project can take a dependency on the original consumer project. For example, the order of operations would be as follows for a simple two-project setup:

1. The `project_a` project runs in a deployment environment and produce public models.
2. The `project_b` project adds `project_a` as a dependency.
3. The `project_b` project runs in a deployment environment and produces public models.
4. The `project_a` project adds `project_b` as a dependency.

If you enable this feature and experience any issues, please be sure to each out to dbt Cloud support.

</detailsToggle>

Expand Down
15 changes: 3 additions & 12 deletions website/docs/docs/collaborate/govern/project-dependencies.md
Original file line number Diff line number Diff line change
Expand Up @@ -95,20 +95,11 @@ with monthly_revenue as (

</File>

**Cycle detection:**
#### Cycle detection

Currently, the default behavior for "project" dependencies enforces that these relationships only go in one direction, meaning that the `jaffle_finance` project could not add a new model that depends, on any public models produced by the `jaffle_marketing` project. dbt will check for cycles across projects and raise errors if any are detected.
import CycleDetection from '/snippets/_mesh-cycle-detection.md';

However, many teams may want to be able to share data assets back and forth between teams. **We've added support for enabling bidirectional dependencies across projects, currently in beta**. To enable this in your account, simply set the environment variable `DBT_CLOUD_PROJECT_CYCLES_ALLOWED` to `TRUE` in all yur dbt Cloud environments. This will allow you to create bidirectional dependencies between projects, so long as there are not any node-level cycles introduced by the new dependency.

When setting up projects that depend on each other, it's important to do so in a stepwise fashion. Each project must run and produce public models before the original producer project can take a dependency on the original consumer project. For example, to enable this in our above example, the order of operations would be as follows:

1. The `jaffle_finance` project runs in a deployment environment and produce public models.
2. The `jaffle_marketing` project adds `jaffle_finance` as a dependency.
3. The `jaffle_marketing` project runs in a deployment environment and produces public models.
4. The `jaffle_finance` project adds `jaffle_marketing` as a dependency.

If you enable this feature and experience any issues, please be sure to each out to dbt Cloud support.
<CycleDetection />

For more guidance on how to use dbt Mesh, refer to the dedicated [dbt Mesh guide](/best-practices/how-we-mesh/mesh-1-intro) and also our freely available [dbt Mesh learning course](https://learn.getdbt.com/courses/dbt-mesh).

Expand Down
14 changes: 14 additions & 0 deletions website/snippets/_mesh-cycle-detection.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,14 @@
Currently, the default behavior for "project" dependencies enforces that these relationships only go in one direction, meaning that the `jaffle_finance` project could not add a new model that depends, on any public models produced by the `jaffle_marketing` project. dbt will check for cycles across projects and raise errors if any are detected.

However, many teams may want to be able to share data assets back and forth between teams. _We've added support for enabling bidirectional dependencies across projects, currently in beta_.

To enable this in your account, set the environment variable `DBT_CLOUD_PROJECT_CYCLES_ALLOWED` to `TRUE` in all your dbt Cloud environments. This allows you to create bidirectional dependencies between projects, so long as the new dependency does not introduce any node-level cycles.

When setting up projects that depend on each other, it's important to do so in a stepwise fashion. Each project must run and produce public models before the original producer project can take a dependency on the original consumer project. For example, the order of operations would be as follows for a simple two-project setup:

1. The `project_a` project runs in a deployment environment and produces public models.
2. The `project_b` project adds `project_a` as a dependency.
3. The `project_b` project runs in a deployment environment and produces public models.
4. The `project_a` project adds `project_b` as a dependency.

If you enable this feature and experience any issues, please reach out to [dbt Cloud support](mailto:[email protected]).

0 comments on commit 4273d57

Please sign in to comment.