columns (4)

Rule: columns_name_convention

For object naming conventions, see the name_convention rule.

Catalog Rule

Why differentiate between manifest and catalog rules?

Catalog rules use both the manifest.json and catalog.json artifacts. Catalog rules require an active database connection to be generated using dbt docs generate. These files can become out of sync during development (for example, when running dbtective in pre-commit hooks), especially if files are moved or renamed and only one of the commands generating manifest.json is run. For more information, see the dbt documentation on manifest.json.

To ensure your catalog is up to date, delete it from the dbt target folder and regenerate it using dbt docs generate. Future updates to dbtective will include an option to automate this process with a specific flag. It's also possible to disable `catalog` based rules using the `--only-manifest` flag.


columns_name_convention details
This rule ensures that column names follow naming conventions based on a specified pattern.

Configuration

  • type: Must be columns_name_convention.
  • applies_to: (optional) List of dbt object types to include.
    • Default: ["models", "seeds", "snapshots"]
    • Options: models, seeds, snapshots, sources
  • pattern: The naming convention pattern to enforce. Can be one of the following presets or a custom regex pattern.
    • Presets:
      • snake_case: lowercase letters, numbers, and underscores (e.g., user_id, created_at)
      • kebab-case: lowercase letters, numbers, and hyphens (e.g., user-id, created-at)
      • camelCase: starts with a lowercase letter, followed by uppercase letters for new words (e.g., userId, createdAt)
      • PascalCase: starts with an uppercase letter, followed by uppercase letters for new words (e.g., UserId, CreatedAt)
    • Custom Regex: Any valid regex pattern to match against column names.
  • data_types: (optional) List of SQL data types to filter columns by. Only columns with these data types will be checked included in the naming convention rule. If not specified, all columns are included.
    • Default: All data types
    • Example: If you want all datetime columns to end with ‘dt’, you can set data_types: ['date', 'date_time', 'timestamp', 'timestamptz'] with pattern .*_dt$
    • Available types: integer, big_int, small_int, tiny_int, decimal, numeric, float, double, real, string, text, varchar, char, date, date_time, time, timestamp, timestamptz, boolean, json, jsonb, array, object, variant, binary, varbinary, uuid, interval
Common Rule Config
  • name: Human-readable name of the rule.
  • severity: "error" (fail) or "warning" (warn only).
    • (optional, defaults to "error" if not specified)
  • description: Human-readable explanation of the rule.
  • includes: List of patterns to explicitly include for this rule.
      Paths are relative to the original_file_path from the manifest.
      Pattern syntax:
    • * matches any characters except / (within a single directory)
    • ** matches any characters including / (across directories)
    • ^ at the start anchors to the beginning of the path
    • $ at the end anchors to the end of the path
    • Without anchors, pattern matches if it appears anywhere in the path (contains)
        Examples:     ^models/staging/ - paths starting with models/staging/     orders - paths containing orders anywhere     .sql$ - paths ending with .sql     ^models/*.sql$ - SQL files directly in models/ folder     ^models/**/*.sql$ - SQL files in any subfolder of models/
  • excludes: List of patterns to explicitly exclude from this rule.
      Uses the same pattern syntax as includes.
      Examples:     ^models/legacy/ - exclude legacy models folder     _deprecated - exclude paths containing _deprecated     ^tests/ - exclude test files
  • model_materializations: Filter models by materialization type. Only applies when applies_to includes models.
      (optional, if not specified all materializations are included)
      Built-in types: table, view, incremental, ephemeral, materialized_view. Custom materializations are also supported.
      Example: ["table", "incremental"]

Example Config

catalog_tests:
  - name: "columns_snake_case"
    type: "columns_name_convention"
    description: "All column names must be snake_case."
    pattern: "snake_case"
    # severity: "warning"  (optional)
    # applies_to: ['models', 'sources']  (optional)
    # includes: ["path/to/include/*"]  (optional)
    # excludes: ["path/to/exclude/*"]  (optional)
[[catalog_tests]]
name = "columns_snake_case"
type = "columns_name_convention"
description = "All column names must be snake_case."
pattern = "snake_case"
# severity = "warning"  # (optional)
# applies_to = ["models", "sources"]  # (optional)
# includes = ["path/to/include/*"]  # (optional)
# excludes = ["path/to/exclude/*"]  # (optional)
[[tool.dbtective.catalog_tests]]
name = "columns_snake_case"
type = "columns_name_convention"
description = "All column names must be snake_case."
pattern = "snake_case"
# severity = "warning"  # (optional)
# applies_to = ["models", "sources"]  # (optional)
# includes = ["path/to/include/*"]  # (optional)
# excludes = ["path/to/exclude/*"]  # (optional)

Example with Custom Regex

catalog_tests:
  - name: "columns_snake_case"
    type: "columns_name_convention"
    description: "All column must be snake_case."
    pattern: "snake_case"
[[catalog_tests]]
name = "columns_snake_case"
type = "columns_name_convention"
description = "All column names must be snake_case."
pattern = "snake_case"
[[tool.dbtective.catalog_tests]]
name = "columns_snake_case"
type = "columns_name_convention"
description = "All column names must be snake_case."
pattern = "snake_case"
Relevant dbt code
-- Example model SQL
SELECT
    snake_case,           -- PASS: snake_case
    camelCase,            -- PASS: camelCase
    PascalCase            -- PASS: PascalCase
FROM users

Rule: columns_all_documented

Catalog Rule

Why differentiate between manifest and catalog rules?

Catalog rules use both the manifest.json and catalog.json artifacts. Catalog rules require an active database connection to be generated using dbt docs generate. These files can become out of sync during development (for example, when running dbtective in pre-commit hooks), especially if files are moved or renamed and only one of the commands generating manifest.json is run. For more information, see the dbt documentation on manifest.json.

To ensure your catalog is up to date, delete it from the dbt target folder and regenerate it using dbt docs generate. Future updates to dbtective will include an option to automate this process with a specific flag. It's also possible to disable `catalog` based rules using the `--only-manifest` flag.

columns_all_documented details
This rule ensures that every dbt object (model, seed, source, macro, etc.) documented their columns (e.g. mentioned them in a `.yaml` file).

Configuration

  • type: Must be columns_all_documented.
  • applies_to: (optional) List of dbt object types to include.
    • Default: ["models", "seeds", "snapshots", "sources", "semantic_models"]
    • Options: models, seeds, snapshots, sources, macros,semantic_models
Common Rule Config
  • name: Human-readable name of the rule.
  • severity: "error" (fail) or "warning" (warn only).
    • (optional, defaults to "error" if not specified)
  • description: Human-readable explanation of the rule.
  • includes: List of patterns to explicitly include for this rule.
      Paths are relative to the original_file_path from the manifest.
      Pattern syntax:
    • * matches any characters except / (within a single directory)
    • ** matches any characters including / (across directories)
    • ^ at the start anchors to the beginning of the path
    • $ at the end anchors to the end of the path
    • Without anchors, pattern matches if it appears anywhere in the path (contains)
        Examples:     ^models/staging/ - paths starting with models/staging/     orders - paths containing orders anywhere     .sql$ - paths ending with .sql     ^models/*.sql$ - SQL files directly in models/ folder     ^models/**/*.sql$ - SQL files in any subfolder of models/
  • excludes: List of patterns to explicitly exclude from this rule.
      Uses the same pattern syntax as includes.
      Examples:     ^models/legacy/ - exclude legacy models folder     _deprecated - exclude paths containing _deprecated     ^tests/ - exclude test files
  • model_materializations: Filter models by materialization type. Only applies when applies_to includes models.
      (optional, if not specified all materializations are included)
      Built-in types: table, view, incremental, ephemeral, materialized_view. Custom materializations are also supported.
      Example: ["table", "incremental"]

Example Config

catalog_tests:
  - name: "all_columns_should_be_documented"
    type: "columns_all_documented"
    description: "Everything must have a description."
    # severity: "warning"  (optional)
    # applies_to: ['models', 'seeds']  (optional)
    # includes: ["path/to/include/*"]
    # excludes: ["path/to/exclude/*"]
[[catalog_tests]]
name = "all_columns_should_be_documented"
type = "columns_all_documented"
description = "Everything must have a description."
# severity = "warning"  # (optional)
# applies_to = ["models", "seeds"]  # (optional)
# includes = ["path/to/include/*"]
# excludes = ["path/to/exclude/*"]
[[tool.dbtective.catalog_tests]]
name = "all_columns_should_be_documented"
type = "columns_all_documented"
description = "Everything must have a description."
# severity = "warning"  # (optional)
# applies_to = ["models", "seeds"]  # (optional)
# includes = ["path/to/include/*"]
# excludes = ["path/to/exclude/*"]
Relevant dbt code
models:
  - name: model_without_columns_documented
    columns:
      - column_1
      - column_2
  # Example if the model has 2 columns
  - name: model_with_missing_documentation_for_column_2
    columns:
      - column_1
  - name: model_without_columns_documented

Rule: columns_have_description

Catalog Rule

Why differentiate between manifest and catalog rules?

Catalog rules use both the manifest.json and catalog.json artifacts. Catalog rules require an active database connection to be generated using dbt docs generate. These files can become out of sync during development (for example, when running dbtective in pre-commit hooks), especially if files are moved or renamed and only one of the commands generating manifest.json is run. For more information, see the dbt documentation on manifest.json.

To ensure your catalog is up to date, delete it from the dbt target folder and regenerate it using dbt docs generate. Future updates to dbtective will include an option to automate this process with a specific flag. It's also possible to disable `catalog` based rules using the `--only-manifest` flag.

columns_have_description details
This rule ensures that every documented column has a non-empty description. Unlike `columns_all_documented` which checks that columns are mentioned in YAML files, this rule verifies that those columns actually have meaningful descriptions.

Configuration

  • type: Must be columns_have_description.
  • applies_to: (optional) List of dbt object types to include.
    • Default: ["models", "seeds", "snapshots", "sources", "semantic_models"]
    • Options: models, seeds, snapshots, sources, macros,semantic_models
Common Rule Config
  • name: Human-readable name of the rule.
  • severity: "error" (fail) or "warning" (warn only).
    • (optional, defaults to "error" if not specified)
  • description: Human-readable explanation of the rule.
  • includes: List of patterns to explicitly include for this rule.
      Paths are relative to the original_file_path from the manifest.
      Pattern syntax:
    • * matches any characters except / (within a single directory)
    • ** matches any characters including / (across directories)
    • ^ at the start anchors to the beginning of the path
    • $ at the end anchors to the end of the path
    • Without anchors, pattern matches if it appears anywhere in the path (contains)
        Examples:     ^models/staging/ - paths starting with models/staging/     orders - paths containing orders anywhere     .sql$ - paths ending with .sql     ^models/*.sql$ - SQL files directly in models/ folder     ^models/**/*.sql$ - SQL files in any subfolder of models/
  • excludes: List of patterns to explicitly exclude from this rule.
      Uses the same pattern syntax as includes.
      Examples:     ^models/legacy/ - exclude legacy models folder     _deprecated - exclude paths containing _deprecated     ^tests/ - exclude test files
  • model_materializations: Filter models by materialization type. Only applies when applies_to includes models.
      (optional, if not specified all materializations are included)
      Built-in types: table, view, incremental, ephemeral, materialized_view. Custom materializations are also supported.
      Example: ["table", "incremental"]

Example Config

catalog_tests:
  - name: "all_columns_must_have_descriptions"
    type: "columns_have_description"
    description: "All documented columns must have non-empty descriptions."
    # severity: "warning"  (optional)
    # applies_to: ['models', 'seeds']  (optional)
    # includes: ["path/to/include/*"]
    # excludes: ["path/to/exclude/*"]
[[catalog_tests]]
name = "all_columns_must_have_descriptions"
type = "columns_have_description"
description = "All documented columns must have non-empty descriptions."
# severity = "warning"  # (optional)
# applies_to = ["models", "seeds"]  # (optional)
# includes = ["path/to/include/*"]
# excludes = ["path/to/exclude/*"]
[[tool.dbtective.catalog_tests]]
name = "all_columns_must_have_descriptions"
type = "columns_have_description"
description = "All documented columns must have non-empty descriptions."
# severity = "warning"  # (optional)
# applies_to = ["models", "seeds"]  # (optional)
# includes = ["path/to/include/*"]
# excludes = ["path/to/exclude/*"]
Relevant dbt code
models:
  - name: customers
    columns:
      - name: id
        description: "Customer ID"  # PASS: has description
      - name: name
        description: ""  # FAIL: empty description
      - name: email
        # FAIL: no description field

Rule: columns_canonical_name

Catalog Rule

Why differentiate between manifest and catalog rules?

Catalog rules use both the manifest.json and catalog.json artifacts. Catalog rules require an active database connection to be generated using dbt docs generate. These files can become out of sync during development (for example, when running dbtective in pre-commit hooks), especially if files are moved or renamed and only one of the commands generating manifest.json is run. For more information, see the dbt documentation on manifest.json.

To ensure your catalog is up to date, delete it from the dbt target folder and regenerate it using dbt docs generate. Future updates to dbtective will include an option to automate this process with a specific flag. It's also possible to disable `catalog` based rules using the `--only-manifest` flag.

columns_canonical_name details

Identifies columns that match specified “invalid” patterns and flags them as violations, suggesting they should be renamed to the canonical name. You can also define exceptions for columns that should be allowed even when matched. Can be both regex or strings.


Configuration

  • type: Must be columns_canonical_name.
  • canonical: The preferred/canonical column name (e.g., zip_code).
  • invalid_names: List of patterns that should be flagged as violations. Each pattern can be:
    • Strings: An exact string match (e.g., postal_code)
    • Regex: A pattern starting with ^, ending with $, or containing .* or .+ (e.g., ^zip.*)
  • exceptions: (optional) List of patterns to exclude from violations. Columns matching these patterns will not be flagged even if they match invalid_names. Uses the same literal/regex format as invalid_names.
  • applies_to: (optional) List of dbt object types to include.
    • Default: ["models", "seeds", "snapshots"]
    • Options: models, seeds, snapshots, sources
Common Rule Config
  • name: Human-readable name of the rule.
  • severity: "error" (fail) or "warning" (warn only).
    • (optional, defaults to "error" if not specified)
  • description: Human-readable explanation of the rule.
  • includes: List of patterns to explicitly include for this rule.
      Paths are relative to the original_file_path from the manifest.
      Pattern syntax:
    • * matches any characters except / (within a single directory)
    • ** matches any characters including / (across directories)
    • ^ at the start anchors to the beginning of the path
    • $ at the end anchors to the end of the path
    • Without anchors, pattern matches if it appears anywhere in the path (contains)
        Examples:     ^models/staging/ - paths starting with models/staging/     orders - paths containing orders anywhere     .sql$ - paths ending with .sql     ^models/*.sql$ - SQL files directly in models/ folder     ^models/**/*.sql$ - SQL files in any subfolder of models/
  • excludes: List of patterns to explicitly exclude from this rule.
      Uses the same pattern syntax as includes.
      Examples:     ^models/legacy/ - exclude legacy models folder     _deprecated - exclude paths containing _deprecated     ^tests/ - exclude test files
  • model_materializations: Filter models by materialization type. Only applies when applies_to includes models.
      (optional, if not specified all materializations are included)
      Built-in types: table, view, incremental, ephemeral, materialized_view. Custom materializations are also supported.
      Example: ["table", "incremental"]

Example Config

catalog_tests:
  - name: "canonical_zip_code"
    type: "columns_canonical_name"
    description: "All zip-related columns should be named 'zip_code'."
    canonical: "zip_code"
    invalid_names:
      - "postal_code"     # literal match
      - "^zip"            # regex: matches zipcode, zip_cd, etc.
    # exceptions:
    #   - "zip_code_legacy"  # allow this specific column
    # severity: "warning"  (optional)
    # applies_to: ['models', 'sources']  (optional)
    # includes: ["path/to/include/*"]  (optional)
    # excludes: ["path/to/exclude/*"]  (optional)
[[catalog_tests]]
name = "canonical_zip_code"
type = "columns_canonical_name"
description = "All zip-related columns should be named 'zip_code'."
canonical = "zip_code"
invalid_names = ["postal_code", "^zip"]
# exceptions = ["zip_code_legacy"]  # (optional)
# severity = "warning"  # (optional)
# applies_to = ["models", "sources"]  # (optional)
# includes = ["path/to/include/*"]  # (optional)
# excludes = ["path/to/exclude/*"]  # (optional)
[[tool.dbtective.catalog_tests]]
name = "canonical_zip_code"
type = "columns_canonical_name"
description = "All zip-related columns should be named 'zip_code'."
canonical = "zip_code"
invalid_names = ["postal_code", "^zip"]
# exceptions = ["zip_code_legacy"]  # (optional)
# severity = "warning"  # (optional)
# applies_to = ["models", "sources"]  # (optional)
# includes = ["path/to/include/*"]  # (optional)
# excludes = ["path/to/exclude/*"]  # (optional)
Relevant dbt code
SELECT
    zip_code,            -- PASS: canonical name
    postal_code,         -- FAIL: matches invalid_names literal
    zipcode,             -- FAIL: matches invalid_names regex ^zip
    zip_code_legacy,     -- PASS: matches exception
    other_column         -- PASS: not in invalid_names
FROM source_table