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
- Guard the call with the adapter type: only call `render_constraints_for_create()` when `adapter.type() == 'databricks'`.
- In cross-adapter macros, branch on `adapter.type()` and fall back to standard constraint rendering for other adapters.
- 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
- Gate Databricks-only relation methods on `adapter.type()` checks.
- Keep cross-warehouse macros free of adapter-specific relation methods.
- Document adapter-specific Jinja APIs in shared macro packages.
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
- describe_dynamic_table is not supported by the {} adapter
- describe_interactive_table is not supported by the {} adapte
- parse_columns_and_constraints is only available for Databric
- {}
- Failed to downcast jinja value to Column; expected Column ob
AI-assisted analysis of dbt-labs/dbt-core@0267ce9170 (2026-09-07).
Data as JSON: /api/errors/f867245fa46356ab.
Report an issue: GitHub.