# dbt™️ Model checks

## `check-column-desc-are-same`

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

Check the models have the same descriptions for the same column names.

**When to use it**

E.g. in two of your models, you have `customer_id` with the description `This is cutomer_id`, but there is one model where column `customer_id` has a description `Something else`. This hook finds discrepancies between column descriptions.
{% endhint %}

**Arguments**

`--ignore`: columns for which do not check whether have a different description.

**Example**

```yaml
repos:
  - repo: https://github.com/dbt-checkpoint/dbt-checkpoint
    rev: v1.0.0
    hooks:
      - id: check-column-desc-are-same
```

**Requirements**

|           Model exists in `manifest.json` 1           | Model exists in `catalog.json` 2 |
| :---------------------------------------------------: | :------------------------------: |
| ❌ Not needed since it also validates properties files |           ❌ 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 model name is obtained from the `SQL` file name.
* The manifest is scanned for a model.
* Modified `yml` files are scanned for a model.
* If any column in the found model has different descriptions than others, the hook fails.
* The description must be in either the yml file **or** the manifest.

***

## `check-column-name-contract`

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

Check that column name abides to a contract, as described in [this blog post](https://emilyriederer.netlify.app/post/column-name-contracts/) by Emily Riederer. A contract consists of a regex pattern and a series of data types.

**When to use it**

You want to make sure your columns follow a contract, e.g. all your boolean columns start with the prefixes `is_`, `has_` or `do_`.
{% endhint %}

**Arguments**

`--pattern`: Regex pattern to match column names. `--dtypes`: Data types. `--exclude`: Regex pattern to exclude files.

**Example**

```yaml
repos:
  - repo: https://github.com/dbt-checkpoint/dbt-checkpoint
    rev: v1.0.0
    hooks:
      - id: check-column-name-contract
        args: [--pattern, "(is|has|do)_.*", --dtypes, boolean text timestamp, "--"]
```

⚠️ 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**

| Model exists in `manifest.json` 1 | Model exists in `catalog.json` 2 |
| :-------------------------------: | :------------------------------: |
|            ❌ Not needed           |               ✅ Yes              |

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 model name is obtained from the `SQL` file name.
* The catalog is scanned for a model.
* If any column in the found model matches the regex pattern and it's data type does not match the contract's data type, the hook fails.
* If any column in the found model matches the contract's data type and does not match the regex pattern, the hook fails.

***

## `check-model-columns-have-desc`

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

Ensures that the model has columns with descriptions in the properties file (usually `schema.yml`).

**When to use it**

You want to make sure that all specified columns in the properties files (usually `schema.yml`) have some description. **This hook does not validate if all database columns are also present in a properties file.**
{% 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`**

**Example**

```yaml
repos:
  - repo: https://github.com/dbt-checkpoint/dbt-checkpoint
    rev: v1.0.0
    hooks:
      - id: check-model-columns-have-desc
```

**Requirements**

|           Model exists in `manifest.json` 1           | Model exists in `catalog.json` 2 |
| :---------------------------------------------------: | :------------------------------: |
| ❌ Not needed since it also validates properties files |           ❌ 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 model name is obtained from the `SQL` file name.
* The manifest is scanned for a model.
* Modified `yml` files are scanned for a model.
* If any column in the found model does not contain a description, the hook fails.
* The description must be in either the yml file **or** the manifest.

**Known limitations**

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

***

## `check-model-has-all-columns`

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

Ensures that all columns in the database are also specified in the properties file. (usually `schema.yml`).

**When to use it**

You want to make sure that you have all the database columns listed in the properties file, or that your properties file no longer contains deleted columns.
{% 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`**\
`--exclude`: Regex pattern to exclude files.

**Example**

```yaml
repos:
  - repo: https://github.com/dbt-checkpoint/dbt-checkpoint
    rev: v1.0.0
    hooks:
      - id: check-model-has-all-columns
```

**Requirements**

| Model exists in `manifest.json` 1 | Model exists in `catalog.json` 2 |
| :-------------------------------: | :------------------------------: |
|               ✅ Yes               |               ✅ Yes              |

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 model name is obtained from the `SQL` file name.
* The manifest is scanned for a model.
* The catalog is scanned for a model.
* If there is any discrepancy between manifest and catalog models, the hook fails.

**Known limitations**

If you did not update the catalog and manifest results can be wrong.

***

## `check-model-has-contract`

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

Checks that model's yaml has:

```yaml
config:
  contract:
    enforced: true
```

**When to use it**

When you want to force developers to define model contracts.
{% 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`**\
`--exclude`: Regex pattern to exclude files.

**Example**

```yaml
repos:
  - repo: https://github.com/dbt-checkpoint/dbt-checkpoint
    rev: v1.0.0
    hooks:
      - id: check-model-has-contract
```

**How it works**

It checks the generated manifest for the contract configuration

***

## `check-model-has-constraints`

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

Checks that model's yaml has specific constraints defined, eg:

```yaml
  - name: products
    config:
      contract:
        enforced: true
    constraints:
      - type: foreign_key
        columns:
          - "product_id"
```

**When to use it**

When you want to force developers to define model constraints.
{% 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`**\
`--constraints`: JSON string escaped by single quotes `--exclude`: Regex pattern to exclude files.

**Example**

```yaml
repos:
  - repo: https://github.com/xasm83/dbt-checkpoint
    rev: v1.0.0
    hooks:
      - id: check-model-has-contract
      - id: check-model-has-constraints
        args: ["--constraints", '[{"type": "primary_key", "columns": ["product_id"]}]', "--"]
```

**How it works**

It checks the generated manifest for the required constraint. Only models with materialization "incremental" or "table" suport constraints. Enforced model contract is required as well. It checks only the keys defined in the '--constraints' parmeter, ie the actual constraint could have more parameters configured in dbt.

***

## `check-model-has-description`

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

Ensures that the model has a description in the properties file (usually `schema.yml`).

**When to use it**

You want to make sure that all models have a description.
{% 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`**\
`--exclude`: Regex pattern to exclude files.

**Example**

```yaml
repos:
  - repo: https://github.com/dbt-checkpoint/dbt-checkpoint
    rev: v1.0.0
    hooks:
      - id: check-model-has-description
```

**Requirements**

|           Model exists in `manifest.json` 1           | Model exists in `catalog.json` 2 |
| :---------------------------------------------------: | :------------------------------: |
| ❌ Not needed since it also validates properties files |           ❌ 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 model name is obtained from the `SQL` file name.
* The manifest is scanned for a model.
* Modified `yml` files are scanned for a model.
* If any model (from a manifest or `yml` files) does not have a description, the hook fails.
* The model description must be in either the yml file **or** the manifest.

**Known limitations**

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

***

## `check-model-has-meta-keys`

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

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

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

**When to use it**

If every model needs to have certain meta keys.
{% 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`**\
`--meta-keys`: list of the required keys in the meta part of the model.\
`--allow-extra-keys`: whether extra keys are allowed. **Default: `False`**.

**Example**

```yaml
repos:
  - repo: https://github.com/dbt-checkpoint/dbt-checkpoint
    rev: v1.0.0
    hooks:
      - id: check-model-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**

|           Model exists in `manifest.json` 1           | Model exists in `catalog.json` 2 |
| :---------------------------------------------------: | :------------------------------: |
| ❌ Not needed since it also validates properties files |           ❌ 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 model name is obtained from the `SQL` file name.
* The manifest is scanned for a model.
* Modified `yml` files are scanned for a model.
* If any model (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 model and then you delete meta keys from a properties file, the hook success since the meta keys is still present in `manifest.json`.

***

## `check-model-has-labels-keys`

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

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

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

**When to use it**

If every model needs to have certain labels keys.
{% 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`**\
`--labels-keys`: list of the required keys in the labels part of the model.\
`--allow-extra-keys`: whether extra keys are allowed. **Default: `False`**.

**Example**

```yaml
repos:
  - repo: https://github.com/dbt-checkpoint/dbt-checkpoint
    rev: v1.0.0
    hooks:
      - id: check-model-has-labels-keys
        args: ['--labels-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**

|           Model exists in `manifest.json` 1           | Model exists in `catalog.json` 2 |
| :---------------------------------------------------: | :------------------------------: |
| ❌ Not needed since it also validates properties files |           ❌ 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 model name is obtained from the `SQL` file name.
* The manifest is scanned for a model.
* Modified `yml` files are scanned for a model.
* If any model (from a manifest or `yml` files) does not have specified labels keys, the hook fails.
* The labels keys must be in either the yml file **or** the manifest.

**Known limitations**

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

***

## `check-model-has-properties-file`

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

Ensures that the model has a properties file (schema file).

**When to use it**

You want to make sure that every model has a properties file.
{% 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`**<br>

**Example**

```yaml
repos:
  - repo: https://github.com/dbt-checkpoint/dbt-checkpoint
    rev: v1.0.0
    hooks:
      - id: check-model-has-properties-file
```

**Requirements**

| Model exists in `manifest.json` 1 | Model exists in `catalog.json` 2 |
| :-------------------------------: | :------------------------------: |
|               ✅ 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 `SQL` files.
* The model name is obtained from the `SQL` file name.
* The manifest is scanned for a model.
* If any model does not have `patch_path`, the hook fails.

**Known limitations**

You need to create a schema file and then rerun your model (`dbt run` or `dbt compile`), otherwise, this hook will fail.

***

## `check-model-has-tests-by-name`

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

Ensures that the model has a number of tests of a certain name (e.g. data, unique).

**When to use it**

You want to make sure that every model has certain tests.
{% 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`**\
`--tests`: key-value pairs of test names. Key is the name of test and value is required minimal number of tests eg. --test unique=1 not\_null=2 (do not put spaces before or after the = sign).\
`--exclude`: Regex pattern to exclude files.

**Example**

```
repos:
  - repo: https://github.com/dbt-checkpoint/dbt-checkpoint
    rev: v1.0.0
    hooks:
      - id: check-model-has-tests-by-name
        args: ["--tests", "unique=1", "data=1", "--"]
```

⚠️ 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**

| Model exists in `manifest.json` 1 | Model exists in `catalog.json` 2 |
| :-------------------------------: | :------------------------------: |
|               ✅ 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 `SQL` files.
* The model name is obtained from the `SQL` file name.
* The manifest is scanned for a model.
* If any model does not have the number of required tests, the hook fails.

***

## `check-model-has-tests-by-type`

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

Ensures that the model has a number of tests of a certain type (data, schema).

**When to use it**

You want to make sure that every model has certain tests.
{% 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`**\
`--tests`: key-value pairs of test types. Key is the type of test (data or schema) and value is required eg. --test data=1 schema=2 (do not put spaces before or after the = sign).\
`--exclude`: Regex pattern to exclude files.

**Example**

```yaml
repos:
  - repo: https://github.com/dbt-checkpoint/dbt-checkpoint
    rev: v1.0.0
    hooks:
      - id: check-model-has-tests-by-type
        args: ["--tests", "schema=1", "data=1", "--"]
```

⚠️ 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**

| Model exists in `manifest.json` 1 | Model exists in `catalog.json` 2 |
| :-------------------------------: | :------------------------------: |
|               ✅ 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 `SQL` files.
* The model name is obtained from the `SQL` file name.
* The manifest is scanned for a model.
* If any model does not have the number of required tests, the hook fails.

***

## `check-model-has-tests-by-group`

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

Ensures that the model has a number of tests from a group of tests.

**When to use it**

You want to make sure that every model has one (or more) of a group of eligible tests (e.g. a set of unique tests).
{% 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`**\
`--tests`: list of test names.\
`--test_cnt`: number of tests required across test group.\
`--exclude`: Regex pattern to exclude files.

**Example**

```
repos:
  - repo: https://github.com/dbt-checkpoint/dbt-checkpoint
    rev: v1.0.0
    hooks:
      - id: check-model-has-tests-by-group
        args: ["--tests", "unique", "unique_where", "--test-cnt", "1", "--"]
```

⚠️ 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**

| Model exists in `manifest.json` 1 | Model exists in `catalog.json` 2 |
| :-------------------------------: | :------------------------------: |
|               ✅ 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 `SQL` files.
* The model name is obtained from the `SQL` file name.
* The manifest is scanned for a model.
* If any model does not have the number of required tests, the hook fails.

***

## `check-model-has-tests`

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

Ensures that the model has a number of tests.

**When to use it**

You want to make sure that every model was tested.
{% 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`**\
`--test-cnt`: Minimum number of tests required.\
`--exclude`: Regex pattern to exclude files.

**Example**

```yaml
repos:
  - repo: https://github.com/dbt-checkpoint/dbt-checkpoint
    rev: v1.0.0
    hooks:
      - id: check-model-has-tests
        args: ["--test-cnt", "2", "--"]
```

⚠️ 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**

| Model exists in `manifest.json` 1 | Model exists in `catalog.json` 2 |
| :-------------------------------: | :------------------------------: |
|               ✅ 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 `SQL` files.
* The model name is obtained from the `SQL` file name.
* The manifest is scanned for a model.
* If any model does not have a number of required tests, the hook fails.

***

#### `check-model-name-contract`

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

Check that model name abides to a contract (similar to [`check-column-name-contract`](#check-column-name-contract)). A contract consists of a regex pattern.

**When to use it**

You want to make sure your model names follow a naming convention (e.g., staging models start with a `stg_` prefix).
{% endhint %}

**Arguments**

`--pattern`: Regex pattern to match model names.\
`--exclude`: Regex pattern to exclude files.

**Example**

```yaml
repos:
  - repo: https://github.com/dbt-checkpoint/dbt-checkpoint
    rev: v1.0.0
    hooks:
      - id: check-model-name-contract
        args: [--pattern, "(base_|stg_).*"]
        files: models/staging/
     - id: check-model-name-contract
       args: [--pattern, "(dim_|fct_).*"]
       files: models/marts/
```

**Requirements**

| Model exists in `manifest.json` 1 | Model exists in `catalog.json` 2 |
| :-------------------------------: | :------------------------------: |
|               ✅ 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 `SQL` files.
* The model name is obtained from the `SQL` file name.
* The catalog is scanned for a model.
* If any model does not match the regex pattern, the hook fails.

***

## `check-model-parents-and-childs`

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

Ensures the model has a specific number (max/min) of parents or/and childs.

**When to use it**

You want to find orphaned models (empty file, hard-coded reference, etc.). Or you want to make sure that every model is used somewhere so you are not e.g. materializing unused tables.
{% 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`**\
`--min-parent-cnt`: Minimal number of parent sources and models. `--max-parent-cnt`: Maximal number of parent sources and models. `--min-child-cnt`: Minimal number of child models. `--max-child-cnt`: Maximal number of child models.

**Example**

```yaml
repos:
  - repo: https://github.com/dbt-checkpoint/dbt-checkpoint
    rev: v1.0.0
    hooks: 
      - id: check-model-parents-and-childs
        args: ["--min-parent-cnt", "2", "--"]
```

⚠️ 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**

| Model exists in `manifest.json` 1 | Model exists in `catalog.json` 2 |
| :-------------------------------: | :------------------------------: |
|               ✅ 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 `SQL` files.
* The model name is obtained from the `SQL` file name.
* The manifest is scanned for a parent and child models.
* If any model does not have a number of required parents/childs, the hook fails.

***

## `check-model-parents-database`

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

Ensures the parent models or sources are from certain database.

**When to use it**

You want to be sure that certain models are using only models from specified database(s).
{% 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`**\
`--whitelist`: list of allowed databases. `--blacklist`: list of disabled databases. `--exclude`: Regex pattern to exclude files.

**Example**

```yaml
repos:
  - repo: https://github.com/dbt-checkpoint/dbt-checkpoint
    rev: v1.0.0
    hooks:
      - id: check-model-parents-database
        args: ["--blacklist", "SRC", "--"]
```

⚠️ 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**

| Model exists in `manifest.json` 1 | Model exists in `catalog.json` 2 |
| :-------------------------------: | :------------------------------: |
|               ✅ 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 `SQL` files.
* The model name is obtained from the `SQL` file name.
* The manifest is scanned for a parent models/sources.
* If any parent model does not have allowed or has disabled databases, the hook fails.

***

## `check-model-parents-name-prefix`

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

Ensures the parent model names have a certain prefix.

**When to use it**

You want to be sure that certain models are using only parent models with a specified prefix
{% 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`**\
`--whitelist`: list of allowed prefixes. `--blacklist`: list of non-allowed prefixes. `--exclude`: Regex pattern to exclude files.

**Example**

```yaml
repos:
  - repo: https://github.com/dbt-checkpoint/dbt-checkpoint
    rev: v1.0.0
    hooks:
      - id: check-model-parents-name-prefix
        exclude: ^models/stage/
        args: ["--whitelist", "stage_", "--"]
```

⚠️ 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**

| Model exists in `manifest.json` 1 | Model exists in `catalog.json` 2 |
| :-------------------------------: | :------------------------------: |
|               ✅ 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 `SQL` files.
* The model name is obtained from the `SQL` file name.
* The manifest is scanned for a parent models/sources.
* If any parent model does not have allowed or has disabled databases, the hook fails.

***

## `check-model-parents-schema`

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

Ensures the parent models or sources are from certain schema.

**When to use it**

You want to be sure that certain models are using only models from specified schema(s).
{% 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`**\
`--whitelist`: list of allowed schemas. `--blacklist`: list of disabled schemas.

**Example**

```yaml
repos:
  - repo: https://github.com/dbt-checkpoint/dbt-checkpoint
    rev: v1.0.0
    hooks:
      - id: check-model-parents-schema
        args: ["--blacklist", "stage", "--"]
```

⚠️ 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**

| Model exists in `manifest.json` 1 | Model exists in `catalog.json` 2 |
| :-------------------------------: | :------------------------------: |
|               ✅ 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 `SQL` files.
* The model name is obtained from the `SQL` file name.
* The manifest is scanned for a parent models/sources.
* If any parent model does not have allowed or has disabled schemas, the hook fails.

***

#### `check-model-tags`

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

Ensures that the model has only valid tags from the provided list.

**When to use it**

Make sure you did not typo in tags.
{% 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`**\
`--tags`: A list of tags that models can have. `--exclude`: Regex pattern to exclude files.

**Example**

```yaml
repos:
  - repo: https://github.com/dbt-checkpoint/dbt-checkpoint
    rev: v1.0.0
    hooks:
      - id: check-model-tags
        args: ["--tags", "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**

| Model exists in `manifest.json` 1 | Model exists in `catalog.json` 2 |
| :-------------------------------: | :------------------------------: |
|               ✅ 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 `SQL` files.
* The model name is obtained from the `SQL` file name.
* The manifest is scanned for a model.
* If any model has different tags than specified, the hook fails.

***

#### `check-model-materialization-by-childs`

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

Checks the model materialization by a given threshold of child models. All models with less child models then the treshold should be materialized as views (or ephemerals), all the rest as tables or incrementals.

**When to use it**

Make sure to increase the efficiency within your dbt run and make use of good materialization choices.
{% 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`**\
`--threshold-childs`: An integer threshold of the number of child models.

**Example**

```yaml
repos:
  - repo: https://github.com/dbt-checkpoint/dbt-checkpoint
    rev: v1.0.0
    hooks:
      - id: check-model-materialization-by-childs
```

**Requirements**

| Model exists in `manifest.json` 1 | Model exists in `catalog.json` 2 |
| :-------------------------------: | :------------------------------: |
|               ✅ 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.


---

# 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-model-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.