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.

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

1.4 deprecation from docs #5597

Merged
merged 3 commits into from
Jun 4, 2024
Merged
Show file tree
Hide file tree
Changes from 1 commit
Commits
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
8 changes: 0 additions & 8 deletions website/dbt-versions.js
Original file line number Diff line number Diff line change
Expand Up @@ -15,10 +15,6 @@ exports.versions = [
version: "1.5",
EOLDate: "2024-04-27",
},
{
version: "1.4",
EOLDate: "2024-01-25",
},
]

exports.versionedPages = [
Expand Down Expand Up @@ -150,10 +146,6 @@ exports.versionedPages = [
"page": "reference/resource-properties/versions",
"firstVersion": "1.5",
},
{
"page": "reference/dbt-jinja-functions/local-md5",
"firstVersion": "1.4",
},
{
"page": "reference/resource-configs/on_configuration_change",
"firstVersion": "1.6",
Expand Down
34 changes: 0 additions & 34 deletions website/docs/docs/build/custom-aliases.md
Original file line number Diff line number Diff line change
Expand Up @@ -73,31 +73,6 @@ To override dbt's alias name generation, create a macro named `generate_alias_na

The default implementation of `generate_alias_name` simply uses the supplied `alias` config (if present) as the model alias, otherwise falling back to the model name. This implementation looks like this:

<VersionBlock lastVersion="1.4">

<File name='get_custom_alias.sql'>

```jinja2
{% macro generate_alias_name(custom_alias_name=none, node=none) -%}

{%- if custom_alias_name is none -%}

{{ node.name }}

{%- else -%}

{{ custom_alias_name | trim }}

{%- endif -%}

{%- endmacro %}

```

</File>

</VersionBlock>

<VersionBlock firstVersion="1.5">

<File name='get_custom_alias.sql'>
Expand Down Expand Up @@ -176,18 +151,9 @@ If these models should indeed have the same database identifier, you can work ar

#### Model versions

<VersionBlock lastVersion="1.4">

New in v1.5

</VersionBlock>

<VersionBlock firstVersion="1.5">

**Related documentation:**
- [Model versions](/docs/collaborate/govern/model-versions)
- [`versions`](/reference/resource-properties/versions#alias)

By default, dbt will create versioned models with the alias `<model_name>_v<v>`, where `<v>` is that version's unique identifier. You can customize this behavior just like for non-versioned models by configuring a custom `alias` or re-implementing the `generate_alias_name` macro.

</VersionBlock>
8 changes: 0 additions & 8 deletions website/docs/docs/build/exposures.md
Original file line number Diff line number Diff line change
Expand Up @@ -12,8 +12,6 @@ Exposures make it possible to define and describe a downstream use of your dbt p

Exposures are defined in `.yml` files nested under an `exposures:` key.

<VersionBlock firstVersion="1.4">

<File name='models/<filename>.yml'>

```yaml
Expand Down Expand Up @@ -42,22 +40,16 @@ exposures:

</File>

</VersionBlock>

### Available properties

_Required:_
- **name**: a unique exposure name written in [snake case](https://en.wikipedia.org/wiki/Snake_case)
- **type**: one of `dashboard`, `notebook`, `analysis`, `ml`, `application` (used to organize in docs site)
- **owner**: `name` or `email` required; additional properties allowed

<VersionBlock firstVersion="1.4">

_Expected:_
- **depends_on**: list of refable nodes, including `metric`, `ref`, and `source`. While possible, it is highly unlikely you will ever need an `exposure` to depend on a `source` directly.

</VersionBlock>

_Optional:_
- **label**: May contain spaces, capital letters, or special characters.
- **url**: Activates and populates the link to **View this exposure** in the upper right corner of the generated documentation site
Expand Down
4 changes: 0 additions & 4 deletions website/docs/docs/build/incremental-strategy.md
Original file line number Diff line number Diff line change
Expand Up @@ -128,8 +128,6 @@ select ...

</File>

<VersionBlock firstVersion="1.4">

### About incremental_predicates

`incremental_predicates` is an advanced use of incremental models, where data volume is large enough to justify additional investments in performance. This config accepts a list of any valid SQL expression(s). dbt does not check the syntax of the SQL statements.
Expand Down Expand Up @@ -208,8 +206,6 @@ The syntax depends on how you configure your `incremental_strategy`:
- There's a decent amount of conceptual overlap with the `insert_overwrite` incremental strategy.
:::

</VersionBlock>

### Built-in strategies

Before diving into [custom strategies](#custom-strategies), it's important to understand the built-in incremental strategies in dbt and their corresponding macros:
Expand Down
4 changes: 0 additions & 4 deletions website/docs/docs/build/packages.md
Original file line number Diff line number Diff line change
Expand Up @@ -145,8 +145,6 @@ To find the latest release for a package, navigate to the `Releases` tab in the

As of v0.14.0, dbt will warn you if you install a package using the `git` syntax without specifying a version (see below).

<VersionBlock firstVersion="1.4">

### Internally hosted tarball URL

Some organizations have security requirements to pull resources only from internal services. To address the need to install packages from hosted environments such as Artifactory or cloud storage buckets, dbt Core enables you to install packages from internally-hosted tarball URLs.
Expand All @@ -160,8 +158,6 @@ packages:

Where `name: 'dbt_utils'` specifies the subfolder of `dbt_packages` that's created for the package source code to be installed within.

</VersionBlock>

### Private packages

#### SSH Key Method (Command Line only)
Expand Down
2 changes: 1 addition & 1 deletion website/docs/docs/build/python-models.md
Original file line number Diff line number Diff line change
Expand Up @@ -256,7 +256,7 @@ def model(dbt, session):
### Materializations

Python models support these materializations:
- `table` <VersionBlock firstVersion="1.4">(default)</VersionBlock>
- `table` (default)
- `incremental`

Incremental Python models support all the same [incremental strategies](/docs/build/incremental-strategy) as their SQL counterparts. The specific strategies supported depend on your adapter. As an example, incremental models are supported on BigQuery with Dataproc for the `merge` incremental strategy; the `insert_overwrite` strategy is not yet supported.
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -56,7 +56,7 @@ my-snowflake-db:
connect_timeout: 10 # default: 10
retry_on_database_errors: False # default: false
retry_all: False # default: false
reuse_connections: False # default: false (available v1.4+)
reuse_connections: False # default: false
```

</File>
Expand Down Expand Up @@ -91,7 +91,7 @@ my-snowflake-db:
connect_timeout: 10 # default: 10
retry_on_database_errors: False # default: false
retry_all: False # default: false
reuse_connections: False # default: false (available v1.4+)
reuse_connections: False # default: false
```

Along with adding the `authenticator` parameter, be sure to run `alter account set allow_client_mfa_caching = true;` in your Snowflake warehouse. Together, these will allow you to easily verify authentication with the DUO Mobile app (skipping this results in push notifications for every model built on every `dbt run`).
Expand Down Expand Up @@ -263,14 +263,10 @@ The `client_session_keep_alive` feature is intended to keep Snowflake sessions a
[Query tags](https://docs.snowflake.com/en/sql-reference/parameters.html#query-tag) are a Snowflake
parameter that can be quite useful later on when searching in the [QUERY_HISTORY view](https://docs.snowflake.com/en/sql-reference/account-usage/query_history.html).

<VersionBlock firstVersion="1.4">

### reuse_connections

During node execution (such as model and test), dbt opens connections against a Snowflake warehouse. Setting this configuration to `True` reduces execution time by verifying credentials only once for each thread.

</VersionBlock>

### retry_on_database_errors

The `retry_on_database_errors` flag along with the `connect_retries` count specification is intended to make retries configurable after the snowflake connector encounters errors of type snowflake.connector.errors.DatabaseError. These retries can be helpful for handling errors of type "JWT token is invalid" when using key pair authentication.
Expand Down
107 changes: 0 additions & 107 deletions website/docs/faqs/Git/gitignore.md
Original file line number Diff line number Diff line change
Expand Up @@ -123,111 +123,4 @@ dbt_modules/

</VersionBlock>

<VersionBlock lastVersion="1.4">

1. Launch the Cloud IDE into the project that is being fixed, by selecting **Develop** on the menu bar.
2. In your **File Explorer**, check to see if a `.gitignore` file exists at the root of your dbt project folder. If it doesn't exist, create a new file.
3. Open the new or existing `gitignore` file, and add the following:

```bash
target/
dbt_packages/
logs/
# legacy -- renamed to dbt_packages in dbt v1
dbt_modules/
```

* **Note** &mdash; You can place these lines anywhere in the file, as long as they're on separate lines. The lines shown are wildcards that will include all nested file and folders. Avoid adding a trailing `'*'` to the lines, such as `target/*`.

For more info on `gitignore` syntax, refer to the [Git docs](https://git-scm.com/docs/gitignore).

4. Save the changes but _don't commit_.
5. Restart the IDE by clicking on the three dots next to the **IDE Status button** on the lower right corner of the IDE screen and select **Restart IDE**.

<Lightbox src="/img/docs/dbt-cloud/cloud-ide/restart-ide.jpg" width="50%" title="Restart the IDE by clicking the three dots on the lower right or click on the Status bar" />

6. Once the IDE restarts, go to the **File Explorer** to delete the following files or folders (if they exist). No data will be lost:
* `target`, `dbt_modules`, `dbt_packages`, `logs`
7. **Save** and then **Commit and sync** the changes.
8. Restart the IDE again using the same procedure as step 5.
9. Once the IDE restarts, use the 'Create a pull request' (PR) button under the **Version Control** menu to start the process of integrating the changes.
10. When the git provider's website opens to a page with the new PR, follow the necessary steps to compelete and merge the PR into the main branch of that repository.

* **Note** &mdash; The 'main' branch might also be called 'master', 'dev', 'qa', 'prod', or something else depending on the organizational naming conventions. The goal is to merge these changes into the root branch that all other development branches are created from.

11. Return to the dbt Cloud IDE and use the **Change Branch** button to switch to the main branch of the project.
12. Once the branch has changed, click the **Pull from remote** button to pull in all the changes.
13. Verify the changes by making sure the files/folders in the `.gitignore `file are in italics.

<Lightbox src="/img/docs/dbt-cloud/cloud-ide/gitignore-italics.jpg" width="50%" title="A dbt project on the main branch that has properly configured gitignore folders (highlighted in italics)."/>


### Fix in the git provider

Sometimes it's necessary to use the git providers web interface to fix a broken `.gitignore` file. Although the specific steps may vary across providers, the general process remains the same.

There are two options for this approach: editing the main branch directly if allowed, or creating a pull request to implement the changes if required:

<Tabs>

<TabItem value="mainbranch2" label="Edit in main branch">

When permissions allow it, it's possible to edit the `.gitignore` directly on the main branch of your repo. Here are the following steps:

1. Go to your repository's web interface.
2. Switch to the main branch, and the root directory of your dbt project.
3. Find the `.gitignore` file. Create a blank one if it doesn't exist.
4. Edit the file in the web interface, adding the following entries:
```bash
target/
dbt_packages/
logs/
# legacy -- renamed to dbt_packages in dbt v1
dbt_modules/
```
5. Commit (save) the file.
6. Delete the following folders from the dbt project root, if they exist. No data or code will be lost:
* `target`, `dbt_modules`, `dbt_packages`, `logs`
7. Commit (save) the deletions to the main branch.
8. Switch to the dbt Cloud IDE, and open the project that you're fixing.
9. Reclone your repo in the IDE by clicking on the three dots next to the **IDE Status** button on the lower right corner of the IDE screen, then select **Reclone Repo**.
* **Note** &mdash; Any saved but uncommitted changes will be lost, so make sure you copy any modified code that you want to keep in a temporary location outside of dbt Cloud.
10. Once you reclone the repo, open the `.gitignore` file in the branch you're working in. If the new changes aren't included, you'll need to merge the latest commits from the main branch into your working branch.
11. Go to the **File Explorer** to verify the `.gitignore` file contains the correct entries and make sure the untracked files/folders in the .gitignore file are in *italics*.
12. Great job 🎉! You've configured the `.gitignore` correctly and can continue with your development!

</TabItem>
<TabItem value="newbranch2" label="Unable to edit main branch">

If you can't edit the `.gitignore` directly on the main branch of your repo, follow these steps:

1. Go to your repository's web interface.
2. Switch to an existing development branch, or create a new branch just for these changes (This is often faster and cleaner).
3. Find the `.gitignore` file. Create a blank one if it doesn't exist.
4. Edit the file in the web interface, adding the following entries:
```bash
target/
dbt_packages/
logs/
# legacy -- renamed to dbt_packages in dbt v1
dbt_modules/
```
5. Commit (save) the file.
6. Delete the following folders from the dbt project root, if they exist. No data or code will be lost:
* `target`, `dbt_modules`, `dbt_packages`, `logs`
7. Commit (save) the deleted folders.
8. Open a merge request using the git provider web interface. The merge request should be attempting to merge the changes into the 'main' branch that all development branches are created from.
9. Follow the necessary procedures to get the branch approved and merged into the 'main' branch. You can delete the branch after the merge is complete.
10. Once the merge is complete, go back to the dbt Cloud IDE, and open the project that you're fixing.
11. Reclone your repo in the IDE by clicking on the three dots next to the **IDE Status** button on the lower right corner of the IDE screen, then select **Reclone Repo**.
* **Note** &mdash; Any saved but uncommitted changes will be lost, so make sure you copy any modified code that you want to keep in a temporary location outside of dbt Cloud.
12. Once you reclone the repo, open the `.gitignore` file in the branch you're working in. If the new changes aren't included, you'll need to merge the latest commits from the main branch into your working branch.
13. Go to the **File Explorer** to verify the `.gitignore` file contains the correct entries and make sure the untracked files/folders in the .gitignore file are in *italics*.
14. Great job 🎉! You've configured the `.gitignore` correctly and can continue with your development!

</TabItem>
</Tabs>

</VersionBlock>

For more info, refer to this [detailed video](https://www.loom.com/share/9b3b8e2b617f41a8bad76ec7e42dd014) for additional guidance.
7 changes: 0 additions & 7 deletions website/docs/faqs/Project/why-version-2.md
Original file line number Diff line number Diff line change
Expand Up @@ -14,10 +14,3 @@ Resource yml files do not currently require this config. We only support `versio

</VersionBlock>

<VersionBlock lastVersion="1.4">

Once upon a time, the structure of these `.yml` files was very different (s/o to anyone who was using dbt back then!). Adding `version: 2` allowed us to make this structure more extensible.

Currently, Version 2 is the only supported version for these files. We kept `version:` around as a required key so that in the future, if we need to introduce a new structure for these files, we'll be able to do this more easily.

</VersionBlock>
43 changes: 0 additions & 43 deletions website/docs/faqs/Troubleshooting/gitignore.md
Original file line number Diff line number Diff line change
Expand Up @@ -38,49 +38,6 @@ dbt_modules/
<Lightbox src="/img/docs/dbt-cloud/cloud-ide/gitignore-italics.jpg" width="50%" title="A dbt project on the main branch that has properly configured gitignore folders (highlighted in italics)."/>


</VersionBlock>

<VersionBlock lastVersion="1.4">

1. In the dbt Cloud IDE, add the following [.gitignore contents](https://github.com/dbt-labs/dbt-starter-project/blob/main/.gitignore) in your dbt project `.gitignore` file:
```bash
target/
dbt_packages/
logs/
# legacy -- renamed to dbt_packages in dbt v1
dbt_modules/
```
2. Go to your `dbt_project.yml` file and add `tmp/` after your `target-path:` and add `log-path: "tmp/logs"`.
* So it should look like: `target-path: "tmp/target"` and `log-path: "tmp/logs"`:

<Lightbox src="/img/docs/dbt-cloud/cloud-ide/project-yml-gitignore.jpg" width="85%" title="Modify your dbt_project.yml file to add tmp/ to the target-path and log-path: 'tmp/logs' to your code."/>

3. Save your changes but _don't commit_.
4. Restart the IDE by clicking on the three dots next to the **IDE Status button** on the lower right of the IDE.

<Lightbox src="/img/docs/dbt-cloud/cloud-ide/restart-ide.jpg" width="50%" title="Restart the IDE by clicking the three dots on the lower right or click on the Status bar" />

5. Select **Restart IDE**.
6. Go back to your dbt project and delete the following four folders (if you have them):
* `target`
* `dbt_modules`
* `dbt_packages`
* `logs`
7. **Save** and then **Commit and sync** your changes.
8. Go back to your `dbt_project.yml` file and undo the modifications you made in **Step 2**.

* Remove `tmp` from your `target-path` and completely remove the `log-path: "tmp/logs"` line.

<Lightbox src="/img/docs/dbt-cloud/cloud-ide/project-yml-clean.jpg" width="85%" title="Reset your dbt_project.yml file by undoing the changes you made in Step 2."/>

9. Restart the IDE again.
10. Delete the `tmp` folder in the **File Explorer**.
11. Create a pull request (PR) under the **Version Control** menu to integrate your new changes.
12. Merge the PR in your git provider page.
13. Switch to your main branch and click on **Pull from remote** to pull in all the changes you made to your main branch. You can verify the changes by making sure the files/folders in the .gitignore file are in italics.

<Lightbox src="/img/docs/dbt-cloud/cloud-ide/gitignore-italics.jpg" width="50%" title="A dbt project on the main branch that has properly configured gitignore folders (highlighted in italics)."/>

</VersionBlock>

For more info, refer to this [detailed video](https://www.loom.com/share/9b3b8e2b617f41a8bad76ec7e42dd014) for additional guidance.
2 changes: 1 addition & 1 deletion website/docs/reference/artifacts/manifest-json.md
Original file line number Diff line number Diff line change
Expand Up @@ -36,7 +36,7 @@ All resources nested within `nodes`, `sources`, `metrics`, `exposures`, `macros`
- `name`: Resource name.
- `unique_id`: `<resource_type>.<package>.<resource_name>`, same as dictionary key
- `package_name`: Name of package that defines this resource.
- `root_path`: Absolute file path of this resource's package. (**Note:** This is removed for most node types in dbt Core v1.4 / manifest v8 to reduce duplicative information across nodes, but it is still present for seeds.)
- `root_path`: Absolute file path of this resource's package. (**Note:** This was removed for most node types in dbt Core v1.4 / manifest v8 to reduce duplicative information across nodes, but it is still present for seeds.)
- `path`: Relative file path of this resource's definition within its "resource path" (`model-paths`, `seed-paths`, etc.).
- `original_file_path`: Relative file path of this resource's definition, including its resource path.

Expand Down
10 changes: 0 additions & 10 deletions website/docs/reference/commands/list.md
Original file line number Diff line number Diff line change
Expand Up @@ -73,16 +73,6 @@ $ dbt ls --select snowplow.* --output json

**Listing JSON output with custom keys**

<VersionBlock lastVersion="1.4">

```
$ dbt ls --select snowplow.* --output json --output-keys "name resource_type description"
{"name": "snowplow_events", "description": "This is a pretty cool model", ...}
{"name": "snowplow_page_views", "description": "This model is even cooler", ...}
...
```
</VersionBlock>

<VersionBlock firstVersion="1.5">

```
Expand Down
Loading
Loading