Skip to content

Commit

Permalink
Revisions
Browse files Browse the repository at this point in the history
  • Loading branch information
jtcohen6 committed Jul 4, 2023
1 parent 23754d6 commit 9659bca
Show file tree
Hide file tree
Showing 4 changed files with 16 additions and 9 deletions.
16 changes: 11 additions & 5 deletions website/docs/docs/collaborate/govern/model-access.md
Original file line number Diff line number Diff line change
Expand Up @@ -140,14 +140,20 @@ It is possible to `ref` a model from another project in two ways:

See ["Project Dependencies"](project-dependencies) for an explanation of the advantages of each approach.

If referencing a model from a package, you have the option of restricting `ref` access (or not) to protected models in that package. For historical reasons, to avoid breaking existing projects, the default behavior is that models in another project can `ref` both protected and public models in an installed package. This is useful for packages containing models for a common data source; you can install the package as source code, and run the models as if they were your own.
#### How do I restrict access to models defined in a package?

If you do wish to restrict `ref` access to _only_ public models in that package, you can set `enforce_access: True` in your package configuration:
The maintainer of a project that can be installed as a package may choose whether to restrict other models' `ref` access to only its public models. The package maintainer does this by setting a `restrict_access` config to `True`. By default, the config is `False`, meaning that:
- Models in the package with `access: protected` may be referenced by models in the root project, as if they were defined in the same project
- Models in the package with `access: private` may be referenced by models in the root project, so long as they also have the same `group` config

When `restrict_access: True`, any `ref` from outside the package to a protected or private model in that package will fail. Only models with `access: public` may be accessed outside the package.

<File name="dbt_project.yml">

```yml
packages:
- git: https://my-org/upstream-project
enforce_access: True # default is False
restrict_access: True
```

</File>

</VersionBlock>
6 changes: 3 additions & 3 deletions website/docs/docs/collaborate/govern/project-dependencies.md
Original file line number Diff line number Diff line change
Expand Up @@ -5,8 +5,8 @@ sidebar_label: "Project dependencies"
description: "Reference public models across dbt projects"
---

:::info
Cross-project `ref` This is a feature of dbt Cloud Enterprise.
:::info Cross-project `ref`
This is a feature of dbt Cloud Enterprise.
:::

dbt Core v1.6 introduces a notion of `dependencies` between dbt projects. You're likely already familiar with installing other projects as [packages](/docs/build/packages), whereby you pull down another project's source code and treat it as your own.
Expand All @@ -27,4 +27,4 @@ The second is new. Unlike installing a package, the models in the `jaffle_financ

Models referenced from a `project`-type dependency must use [two-argument `ref`](/reference/dbt-jinja-functions/ref#two-argument-variant), including the project name. Only public models can be accessed in this way.

It's equally possible to install the `jaffle_finance` project as a `package` dependency. This will pull down its full source code., and require dbt to parse all its contents. dbt will expect you to configure and run those models as your own. This can be a useful pattern to achieve certain types of unified deployments in production. In development, it can add significant complexity and latency.
It is equally possible to install the `jaffle_finance` project as a `package` dependency. This will pull down its full source code, and require dbt to parse all its contents. dbt will expect you to configure and run those models as your own. This can be a useful pattern to achieve certain types of unified deployments in production, or to make a coordinated change across multiple projects in development. It can add significant complexity and latency, however, when working within the narrower scope of a single project.
Original file line number Diff line number Diff line change
Expand Up @@ -27,7 +27,7 @@ dbt Labs is committed to providing backward compatibility for all versions 1.x,

## New and changed documentation

[Project dependencies](project-dependencies): Introduce `dependencies.yml`. Allow enforcing model access (public vs. protected/private) across project/package boundaries. Enable cross-project `ref` of public models, without requiring the installation of upstream source code, as a feature of dbt Cloud Enterprise.
[Project dependencies](/docs/collaborate/govern/project-dependencies): Introduce `dependencies.yml`. Allow enforcing model access (public vs. protected/private) across project/package boundaries. Enable cross-project `ref` of public models, without requiring the installation of upstream source code, as a feature of dbt Cloud Enterprise.

### Quick hits

Expand Down
1 change: 1 addition & 0 deletions website/docs/reference/dbt_project.yml.md
Original file line number Diff line number Diff line change
Expand Up @@ -83,6 +83,7 @@ vars:
- macro_namespace: packagename
search_order: [packagename]

[restrict-access](/docs/collaborate/govern/model-access/how-do-i-restrict-access-to-models-defined-in-a-package): true | false
```
</File>

0 comments on commit 9659bca

Please sign in to comment.