dbt-labs/dbt-core · error

{} relation creation from Jinja values

Error message

{} relation creation from Jinja values

What it means

create_from constructs a new BaseRelation from Jinja-provided values (as dbt-core's Relation.create_from does). The default BaseRelation implementation in this codebase is a parse-time stub, so create_from panics with unimplemented!() reporting the adapter type — real relation creation from Jinja values must go through adapter-specific relation classes.

Source

Thrown at crates/dbt-adapter/src/relation/relation_impl.rs:667

                .unwrap_or(false),
            _ => false,
        }
    }

    fn has_information(&self) -> bool {
        self.metadata.is_some()
    }

    fn as_any(&self) -> &dyn Any {
        self
    }

    fn to_owned(&self) -> Arc<dyn BaseRelation> {
        Arc::new(self.clone())
    }

    fn create_from(&self) -> Result<Arc<dyn BaseRelation>, minijinja::Error> {
        unimplemented!("{} relation creation from Jinja values", self.adapter_type)
    }

    fn database(&self) -> Option<&str> {
        if self.is_parse_time {
            return None;
        }

        self.path.database.as_deref()
    }

    fn schema(&self) -> Option<&str> {
        self.path.schema.as_deref()
    }

    fn identifier(&self) -> Option<&str> {
        self.path.identifier.as_deref()
    }

View on GitHub (pinned to 0267ce9170)

Solutions

1. Use the adapter-specific relation's create_from (e.g. the adapter's bound Relation class exposed via api.Relation in Jinja) instead of the generic BaseRelation.
2. Construct the relation directly in Rust with the appropriate fields rather than routing through the Jinja interop method.
3. Ensure the macro runs in an execution (not parse-only) context where a real adapter relation is bound.

Example fix

// before (Jinja)
{% set rel = api.Relation.create_from(database=this.database, schema=this.schema, identifier="my_table") %}

// after
{% set rel = adapter.get_relation(database=this.database, schema=this.schema, identifier="my_table") %}

{% set rel_class = adapter.Relation if adapter is defined else none %}
{% if rel_class is none %}{% do exceptions.raise_compiler_error("create_from unavailable at parse time") %}{% endif %}

When it happens

Trigger: Calling .create_from(...) on a BaseRelation instance from Jinja/macros — e.g. Relation.create_from(database=..., schema=..., identifier=...) — when the backing object is the generic parse-time relation rather than an adapter-specific implementation.

Common situations: Macros ported from dbt-core that rely on api.Relation.create_from; custom materializations creating relations at runtime; running at parse time where the generic relation stub is bound instead of the adapter's relation class.

Related errors

• RelationConfigBaseObject does not support method: {}
• group_by with function key
• get_temp_relation_path: relation.database is required
• get_temp_relation_path: relation.identifier is required
• Unknown method on BaseRelationObject: '{name}'

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