Skip to content
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.

Sign up for GitHub

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

Deprecate 1.1 and changelog from docs #4140

Merged
merged 3 commits into from
Sep 27, 2023
Merged

Deprecate 1.1 and changelog from docs #4140

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
9ea3753
Deprecate 1.1 and changelog from docs
matthewshaver Sep 27, 2023
5fde9c2
Merge branch 'current' into 1dot1-deprecation
matthewshaver Sep 27, 2023
79423e9
Merge branch 'current' into 1dot1-deprecation
matthewshaver Sep 27, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
120 changes: 52 additions & 68 deletions website/dbt-versions.js
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -24,13 +24,61 @@ exports.versions = [
version: "1.2",
EOLDate: "2023-07-26",
},
{
version: "1.1",
EOLDate: "2023-04-28",
},
]

exports.versionedPages = [
{
"page": "docs/build/build-metrics-intro",
"firstVersion": "1.6",
},
{
"page": "docs/build/sl-getting-started",
"firstVersion": "1.6",
},
{
"page": "docs/build/about-metricflow",
"firstVersion": "1.6",
},
{
"page": "docs/build/join-logic",
"firstVersion": "1.6",
},
{
"page": "docs/build/validation",
"firstVersion": "1.6",
},
{
"page": "docs/build/semantic-models",
"firstVersion": "1.6",
},
{
"page": "docs/build/group-by",
"firstVersion": "1.6",
},
{
"page": "docs/build/entities",
"firstVersion": "1.6",
},
{
"page": "docs/build/metrics-overview",
"firstVersion": "1.6",
},
{
"page": "docs/build/cumulative",
"firstVersion": "1.6",
},
{
"page": "docs/build/derived",
"firstVersion": "1.6",
},
{
"page": "docs/build/measure-proxy",
"firstVersion": "1.6",
},
{
"page": "docs/build/ratio",
"firstVersion": "1.6",
},
{
"page": "reference/commands/clone",
"firstVersion": "1.6",
Expand Down Expand Up @@ -122,70 +170,6 @@ exports.versionedPages = [
{
"page": "reference/resource-configs/grants",
"firstVersion": "1.2",
},
{
"page": "docs/contributing/testing-a-new-adapter",
"firstVersion": "1.1",
},
{
"page": "reference/dbt-jinja-functions/selected_resources",
"firstVersion": "1.1",
},
{
"page": "reference/dbt-jinja-functions/print",
"firstVersion": "1.1",
},
{
"page": "docs/build/build-metrics-intro",
"firstVersion": "1.6",
},
{
"page": "docs/build/sl-getting-started",
"firstVersion": "1.6",
},
{
"page": "docs/build/about-metricflow",
"firstVersion": "1.6",
},
{
"page": "docs/build/join-logic",
"firstVersion": "1.6",
},
{
"page": "docs/build/validation",
"firstVersion": "1.6",
},
{
"page": "docs/build/semantic-models",
"firstVersion": "1.6",
},
{
"page": "docs/build/group-by",
"firstVersion": "1.6",
},
{
"page": "docs/build/entities",
"firstVersion": "1.6",
},
{
"page": "docs/build/metrics-overview",
"firstVersion": "1.6",
},
{
"page": "docs/build/cumulative",
"firstVersion": "1.6",
},
{
"page": "docs/build/derived",
"firstVersion": "1.6",
},
{
"page": "docs/build/measure-proxy",
"firstVersion": "1.6",
},
{
"page": "docs/build/ratio",
"firstVersion": "1.6",
}
]

Expand Down
2 changes: 0 additions & 2 deletions website/docs/docs/build/custom-databases.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -54,8 +54,6 @@ select * from ...

### generate_database_name

<Changelog>New in v0.16.0</Changelog>

The database name generated for a model is controlled by a macro called `generate_database_name`. This macro can be overridden in a dbt project to change how dbt generates model database names. This macro works similarly to the [generate_schema_name](/docs/build/custom-schemas#advanced-custom-schema-configuration) macro.

To override dbt's database name generation, create a macro named `generate_database_name` in your own dbt project. The `generate_database_name` macro accepts two arguments:
Expand Down
7 changes: 0 additions & 7 deletions website/docs/docs/build/custom-schemas.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -180,13 +180,6 @@ The following context methods _are_ available in the `generate_schema_name` macr

### Which vars are available in generate_schema_name?

<Changelog>

Variable semantics have changed in dbt v0.17.0. See the [migration guide](/guides/migration/versions)
for more information on these changes.

</Changelog>

Globally-scoped variables and variables defined on the command line with
[--vars](/docs/build/project-variables) are accessible in the `generate_schema_name` context.

Expand Down
7 changes: 0 additions & 7 deletions website/docs/docs/build/exposures.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -4,13 +4,6 @@ sidebar_label: "Exposures"
id: "exposures"
---

<Changelog>

* **v0.18.1**: Exposures are new!
* **v0.20.0**: Exposures support `tags` and `meta` properties

</Changelog>

Exposures make it possible to define and describe a downstream use of your dbt project, such as in a dashboard, application, or data science pipeline. By defining exposures, you can then:
- run, test, and list resources that feed into your exposure
- populate a dedicated page in the auto-generated [documentation](/docs/collaborate/documentation) site with context relevant to data consumers
Expand Down
121 changes: 0 additions & 121 deletions website/docs/docs/build/hooks-operations.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -68,127 +68,6 @@ You can use hooks to provide database-specific functionality not available out-o
</File>


</VersionBlock>

<VersionBlock lastVersion="1.1">

### Examples using hooks

Here's a minimal example of using hooks to grant privileges. For more information, see [`on-run-start` & `on-run-end` hooks](/reference/project-configs/on-run-start-on-run-end) and [`pre-hook` & `post-hook`](/reference/resource-configs/pre-hook-post-hook) reference sections.

<File name='dbt_project.yml'>

```yml
on-run-end:
- "grant usage on {{ target.schema }} to role reporter"

models:
+post-hook:
- "grant select on {{ this }} to role reporter"

```

</File>

You can also apply the `post-hook` to individual models using a `config` block:

<File name='models/<model_name>.sql'>

```sql
{{ config(
post_hook=[
"grant select on {{ this }} to role reporter"
]
) }}

select ...

```

</File>

You should use database-specific syntax when appropriate:

<WHCode>

<div warehouse="BigQuery">

<File name='models/<model_name>.sql'>

```sql
{{ config(
post_hook=[
'grant `roles/bigquery.dataViewer` on {{ this.type }} {{ this }} to "user:[email protected]"'
]
) }}

select ...

```

</File>

</div>

<div warehouse="Databricks">

<File name='models/<model_name>.sql'>

```sql
{{ config(
post_hook=[
"grant select on {{ this }} to `[email protected]`"
]
) }}

select ...

```

</File>

</div>

<div warehouse="Redshift">

<File name='models/<model_name>.sql'>

```sql
{{ config(
post_hook=[
"grant select on {{ this }} to reporter"
]
) }}

select ...

```

</File>

</div>

<div warehouse="Snowflake">

<File name='models/<model_name>.sql'>

```sql
{{ config(
post_hook=[
"grant select on {{ this }} to role reporter"
]
) }}

select ...

```

</File>

</div>

</WHCode>

</VersionBlock>

### Calling a macro in a hook
Expand Down
4 changes: 0 additions & 4 deletions website/docs/docs/build/incremental-models.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -79,8 +79,6 @@ A `unique_key` enables updating existing rows instead of just appending new rows

Not specifying a `unique_key` will result in append-only behavior, which means dbt inserts all rows returned by the model's SQL into the preexisting target table without regard for whether the rows represent duplicates.

<VersionBlock firstVersion="1.1">

The optional `unique_key` parameter specifies a field (or combination of fields) that define the grain of your model. That is, the field(s) identify a single unique row. You can define `unique_key` in a configuration block at the top of your model, and it can be a single column name or a list of column names.

The `unique_key` should be supplied in your model definition as a string representing a single column or a list of single-quoted column names that can be used together, for example, `['col1', 'col2', …])`. Columns used in this way should not contain any nulls, or the incremental model run may fail. Either ensure that each column has no nulls (for example with `coalesce(COLUMN_NAME, 'VALUE_IF_NULL')`), or define a single-column [surrogate key](/terms/surrogate-key) (for example with [`dbt_utils.generate_surrogate_key`](https://github.com/dbt-labs/dbt-utils#generate_surrogate_key-source)).
Expand All @@ -95,8 +93,6 @@ When you pass a list in this way, please ensure that each column does not contai
Alternatively, you can define a single-column [surrogate key](/terms/surrogate-key), for example with [`dbt_utils.generate_surrogate_key`](https://github.com/dbt-labs/dbt-utils#generate_surrogate_key-source).
:::

</VersionBlock>

When you define a `unique_key`, you'll see this behavior for each row of "new" data returned by your dbt model:

* If the same `unique_key` is present in the "new" and "old" model data, dbt will update/replace the old row with the new row of data. The exact mechanics of how that update/replace takes place will vary depending on your database, [incremental strategy](#about-incremental_strategy), and [strategy specific configs](#strategy-specific-configs).
Expand Down
Loading
Loading