dbt-labs/dbt-core · error

render_constraints_for_create is only available for Databric

Error message

render_constraints_for_create is only available for Databricks relations

What it means

The `render_constraints_for_create` Jinja method on a relation object is only implemented for Databricks relations. The object method attempts a downcast of the wrapped relation to the Databricks `Relation` type and throws this minijinja InvalidOperation error when the relation is any other adapter's relation type. It is a deliberate adapter-capability guard, not a bug.

Source

Thrown at crates/dbt-adapter/src/relation/relation_object.rs:136

                        minijinja::Error::new(
                            minijinja::ErrorKind::InvalidOperation,
                            "enrich constraints must contain TypedConstraint objects",
                        )
                    })
            })
            .collect::<Result<Vec<_>, _>>()?;
        let enriched = dbx.enrich(&constraints);
        Ok(RelationObject::new(Arc::new(enriched)).into_value())
    }

    /// Databricks: render constraints DDL for CREATE TABLE
    fn relation_render_constraints_for_create(self: &Arc<Self>) -> Result<Value, minijinja::Error> {
        let dbx = self
            .relation
            .as_any()
            .downcast_ref::<Relation>()
            .ok_or_else(|| {
                minijinja::Error::new(
                    minijinja::ErrorKind::InvalidOperation,
                    "render_constraints_for_create is only available for Databricks relations",
                )
            })?;
        Ok(Value::from(dbx.render_constraints_for_create()))
    }
}

/// Always returns the unfiltered relation string (via [`BaseRelation::render_self_as_str`]),
/// reference: https://github.com/dbt-labs/dbt-adapters/blob/616a8d3cb595605872c011070c240e7a2b825d79/dbt-adapters/src/dbt/adapters/base/relation.py#L268-L269
fn render_without_filter(ro: &Arc<RelationObject>) -> Value {
    let rendered = ro.render_self_as_str();
    if rendered.is_empty() {
        none_value()
    } else {
        Value::from(rendered)
    }
}

View on GitHub (pinned to 0267ce9170)

Solutions

  1. Guard the call with the adapter type: only call `render_constraints_for_create()` when `adapter.type() == 'databricks'`.
  2. In cross-adapter macros, branch on `adapter.type()` and fall back to standard constraint rendering for other adapters.
  3. Ensure the relation object was created by the Databricks adapter (e.g. via `api.Relation.create` on the Databricks adapter), not a generic base relation.

Example fix

// before
{{ relation.render_constraints_for_create() }}
// after
{% if adapter.type() == 'databricks' %}
  {{ relation.render_constraints_for_create() }}
{% else %}
  {{ render_standard_constraints(relation) }}
{% endif %}
Defensive patterns

Strategy: validation

Validate before calling

{% if adapter.type() == 'databricks' %}
  {{ relation.render_constraints_for_create() }}
{% else %}
  {{ render_standard_constraints(relation) }}
{% endif %}

Prevention

When it happens

Trigger: Calling `relation.render_constraints_for_create()` from a macro or Jinja template while running under a non-Databricks adapter, or when the wrapped value is a generic/base relation rather than the concrete Databricks Relation object.

Common situations: Porting a Databricks-specific macro (e.g. model constraints in CREATE TABLE) to another warehouse like Snowflake or BigQuery; a shared macro package that assumes Databricks; calling the method on a relation built from a generic BaseRelation instead of the adapter's relation.

Understand the failure class

Background: UnsupportedOperationException and "is not supported" errors: when a library deliberately refuses a call — this error's family across 30 libraries.

Related errors


AI-assisted analysis of dbt-labs/dbt-core@0267ce9170 (2026-09-07). Data as JSON: /api/errors/f867245fa46356ab. Report an issue: GitHub.