# dbt™️ checks

## `check-macro-has-meta-keys`

{% hint style="info" %}
**What it does**

Ensures that the macro has a list of valid meta keys. (usually `schema.yml`).

**When to use it**

If every macro needs to have certain meta keys.
{% endhint %}

By default, it does not allow the macro to have any other meta keys other than the ones required. An optional argument can be used to allow for extra keys.

**Arguments**

`--manifest`: location of `manifest.json` file. Usually `target/manifest.json`. This file contains a full representation of dbt project. **Default: `target/manifest.json`**\
`--meta-keys`: list of the required keys in the meta part of the macro.\
`--allow-extra-keys`: whether extra keys are allowed. **Default: `False`**.

**Example**

```yaml
repos:
  - repo: https://github.com/dbt-checkpoint/dbt-checkpoint
    rev: v1.2.1
    hooks:
      - id: check-macro-has-meta-keys
        args: ['--meta-keys', 'foo', 'bar', "--"]
```

⚠️ do not forget to include `--` as the last argument. Otherwise `pre-commit` would not be able to separate a list of files with args.

**Requirements**

| Macro exists in `manifest.json` *1* | Macro exists in `catalog.json` [2](https://github.com/dbt-checkpoint/dbt-checkpoint/blob/main/HOOKS.md#f2) |
| :---------------------------------: | :--------------------------------------------------------------------------------------------------------: |
|                ✅ Yes                |                                                ❌ Not needed                                                |

1 It means that you need to run `dbt parse` before run this hook (dbt >= 1.5).\
2 It means that you need to run `dbt docs generate` before run this hook.

**How it works**

* Hook takes all changed `yml` files.
* The manifest is scanned for a macro.
* If any macro (from a manifest or `yml` files) does not have specified meta keys, the hook fails.
* The meta keys must be in either the yml file **or** the manifest.

**Known limitations**

If you `run` your macro and then you delete meta keys from a properties file, the hook success since the meta keys is still present in `manifest.json`.

***

## `check-seed-has-meta-keys`

{% hint style="info" %}
**What it does**

Ensures that the seed has a list of valid meta keys. (usually `schema.yml`).

**When to use it**

If every seed needs to have certain meta keys.
{% endhint %}

By default, it does not allow the seed to have any other meta keys other than the ones required. An optional argument can be used to allow for extra keys.

**Arguments**

`--manifest`: location of `manifest.json` file. Usually `target/manifest.json`. This file contains a full representation of dbt project. **Default: `target/manifest.json`**\
`--meta-keys`: list of the required keys in the meta part of the seed.\
`--allow-extra-keys`: whether extra keys are allowed. **Default: `False`**.

**Example**

```yaml
repos:
  - repo: https://github.com/dbt-checkpoint/dbt-checkpoint
    rev: v1.2.1
    hooks:
      - id: check-seed-has-meta-keys
        args: ['--meta-keys', 'foo', 'bar', "--"]
```

⚠️ do not forget to include `--` as the last argument. Otherwise `pre-commit` would not be able to separate a list of files with args.

**Requirements**

| Seed exists in `manifest.json` *1* | Seed exists in `catalog.json` [2](https://github.com/dbt-checkpoint/dbt-checkpoint/blob/main/HOOKS.md#f2) |
| :--------------------------------: | :-------------------------------------------------------------------------------------------------------: |
|                ✅ Yes               |                                                ❌ Not needed                                               |

1 It means that you need to run `dbt parse` before run this hook (dbt >= 1.5).\
2 It means that you need to run `dbt docs generate` before run this hook.

**How it works**

* Hook takes all changed `yml` files.
* The manifest is scanned for a seed.
* If any seed (from a manifest or `yml` files) does not have specified meta keys, the hook fails.
* The meta keys must be in either the yml file **or** the manifest.

**Known limitations**

If you `run` your seed and then you delete meta keys from a properties file, the hook success since the meta keys is still present in `manifest.json`.

***

## `check-snapshot-has-meta-keys`

{% hint style="info" %}
**What it does**

Ensures that the snapshot has a list of valid meta keys. (usually `schema.yml`).

**When to use it**

If every snapshot needs to have certain meta keys.
{% endhint %}

By default, it does not allow the snapshot to have any other meta keys other than the ones required. An optional argument can be used to allow for extra keys.

**Arguments**

`--manifest`: location of `manifest.json` file. Usually `target/manifest.json`. This file contains a full representation of dbt project. **Default: `target/manifest.json`**\
`--meta-keys`: list of the required keys in the meta part of the snapshot.\
`--allow-extra-keys`: whether extra keys are allowed. **Default: `False`**.

**Example**

```yaml
repos:
  - repo: https://github.com/dbt-checkpoint/dbt-checkpoint
    rev: v1.2.1
    hooks:
      - id: check-snapshot-has-meta-keys
        args: ['--meta-keys', 'foo', 'bar', "--"]
```

⚠️ do not forget to include `--` as the last argument. Otherwise `pre-commit` would not be able to separate a list of files with args.

**Requirements**

| Snapshot exists in `manifest.json` *1* | Snapshot exists in `catalog.json` [2](https://github.com/dbt-checkpoint/dbt-checkpoint/blob/main/HOOKS.md#f2) |
| :------------------------------------: | :-----------------------------------------------------------------------------------------------------------: |
|                  ❌ Not                 |                                                  ❌ Not needed                                                 |

1 It means that you need to run `dbt parse` before run this hook (dbt >= 1.5).\
2 It means that you need to run `dbt docs generate` before run this hook.

**How it works**

* Hook takes all changed `yml` and `sql` files.
* The manifest is scanned for a snapshot.
* If any snapshot (from a manifest or `yml` files) does not have specified meta keys, the hook fails.
* The meta keys must be in either the yml file **or** the manifest.

**Known limitations**

If you `run` your snapshot and then you delete meta keys from a properties file, the hook success since the meta keys is still present in `manifest.json`.

***

## `check-test-has-meta-keys`

{% hint style="info" %}
**What it does**

Ensures that the test has a list of valid meta keys. (usually `schema.yml`).

**When to use it**

If every test needs to have certain meta keys.
{% endhint %}

By default, it does not allow the test to have any other meta keys other than the ones required. An optional argument can be used to allow for extra keys.

**Arguments**

`--manifest`: location of `manifest.json` file. Usually `target/manifest.json`. This file contains a full representation of dbt project. **Default: `target/manifest.json`**\
`--meta-keys`: list of the required keys in the meta part of the test.\
`--allow-extra-keys`: whether extra keys are allowed. **Default: `False`**.

**Example**

```yaml
repos:
  - repo: https://github.com/dbt-checkpoint/dbt-checkpoint
    rev: v1.2.1
    hooks:
      - id: check-test-has-meta-keys
        args: ['--meta-keys', 'foo', 'bar', "--"]
```

⚠️ do not forget to include `--` as the last argument. Otherwise `pre-commit` would not be able to separate a list of files with args.

**Requirements**

| Test exists in `manifest.json` *1* | Test exists in `catalog.json` *2* |
| :--------------------------------: | :-------------------------------: |
|                ❌ Not               |            ❌ Not needed           |

1 It means that you need to run `dbt parse` before run this hook (dbt >= 1.5).\
2 It means that you need to run `dbt docs generate` before run this hook.

**How it works**

* Hook takes all changed `sql` files.
* The manifest is scanned for a test.
* If any test (from a manifest or `sql` files) does not have specified meta keys, the hook fails.
* The meta keys must be in either the yml file **or** the manifest.

**Known limitations**

If you `run` your test and then you delete meta keys from a properties file, the hook success since the meta keys is still present in `manifest.json`.

***

## `check-database-casing-consistency`

{% hint style="info" %}
**What it does**

compare Manifest and Catalog to ensure DB and Schemas have the same casing.

**When to use it**

If you want to make sure your dbt project (Manifest) and database (Catalog) are db.schema consistent
{% endhint %}

**Arguments**

`--manifest`: location of `manifest.json` file. Usually `target/manifest.json`. This file contains a full representation of dbt project. **Default: `target/manifest.json`**\
`--catalog`: location of `catalog.json` file. Usually `target/catalog.json`. dbt uses this file to render information like column types and table statistics into the docs site. In dbt-checkpoint is used for column operations. **Default: `target/catalog.json`**

**Example**

```yaml
repos:
  - repo: https://github.com/dbt-checkpoint/dbt-checkpoint
    rev: v1.2.1
    hooks:
      - id: check-database-casing-consistency
```

**How it works**

It compares models and sources databases and schemas in `manifest vs catalog`. If a db/schema in one of them presents a different casing, the hook fails.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.paradime.io/app-help/documentation/integrations/code-ide/pre-commit/dbt-tm-checkpoint-hooks/dbt-tm-checks.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.