dbt-labs/dbt-core · error

not yet implemented

Error message

not yet implemented

What it means

This is a Rust `todo!()` panic from `get_field_sql_type_metadata_key` in crates/dbt-adapter/src/sql_types.rs:556. The function maps an `AdapterType` to the metadata column key used to read field SQL types (e.g. `BIGQUERY_METADATA_SQL_TYPE_KEY`); the `Databricks` arm was left as a placeholder, so it panics with 'not yet implemented'. It marks Databricks metadata-key mapping as unfinished.

Source

Thrown at crates/dbt-adapter/src/sql_types.rs:556

            metadata.insert(
                ARROW_FIELD_SNOWFLAKE_FIELD_WIDTH_METADATA_KEY.to_string(),
                max_len.to_string(),
            );
        }
        _ => {}
    }

    let field = field.with_metadata(metadata);

    Ok(field)
}

pub const fn get_field_sql_type_metadata_key(adapter_type: AdapterType) -> &'static str {
    match adapter_type {
        AdapterType::Bigquery => BIGQUERY_METADATA_SQL_TYPE_KEY,
        AdapterType::Redshift => REDSHIFT_METADATA_SQL_TYPE_KEY,
        AdapterType::Snowflake => SNOWFLAKE_METADATA_SQL_TYPE_KEY,
        AdapterType::Databricks => todo!(),
        AdapterType::Postgres => todo!(),
        AdapterType::Salesforce => todo!(),
        AdapterType::Spark => todo!(),
        AdapterType::DuckDB | AdapterType::LakeCompute => todo!(),
        AdapterType::Fabric => FABRIC_METADATA_SQL_TYPE_KEY,
        AdapterType::ClickHouse => CLICKHOUSE_METADATA_SQL_TYPE_KEY,
        AdapterType::Exasol => "DATA_TYPE",
        AdapterType::Starburst => todo!(),
        AdapterType::Athena => todo!(),
        AdapterType::Trino => todo!(),
        AdapterType::Dremio => todo!(),
        AdapterType::Oracle => todo!(),
        AdapterType::Datafusion => todo!(),
    }
}

pub fn original_type_string<'a>(
    adapter_type: AdapterType,

View on GitHub (pinned to 0267ce9170)

Solutions

  1. Implement the `Databricks` arm, returning the correct metadata column key constant (Databricks/Spark SQL typically uses `data_type`)
  2. Add a compile/test-time guard so Databricks column rendering fails fast with a descriptive error instead of a raw panic
  3. Use an adapter whose metadata key is implemented while rendering fields, or extend `field_to_string` to handle Databricks explicitly

Example fix

// before
AdapterType::Databricks => todo!(),
// after
AdapterType::Databricks => "DATA_TYPE",
Defensive patterns

Strategy: validation

Validate before calling

fn metadata_key_supported(t: AdapterType) -> bool {
    !matches!(t, AdapterType::Databricks)
}
if !metadata_key_supported(adapter_type) {
    return Err(format!("no metadata sql type key defined for {adapter_type:?}"));
}

Type guard

fn metadata_key_supported(t: AdapterType) -> bool {
    matches!(t, AdapterType::Bigquery | AdapterType::Redshift | AdapterType::Snowflake | AdapterType::Fabric | AdapterType::ClickHouse | AdapterType::Exasol)
}

Try / catch

match std::panic::catch_unwind(|| get_field_sql_type_metadata_key(adapter_type)) {
    Ok(k) => k,
    Err(_) => return Err("metadata sql type key unimplemented for this adapter"),
}

Prevention

When it happens

Trigger: Calling `get_field_sql_type_metadata_key(AdapterType::Databricks)`, which happens via `field_to_string` when serializing a field's SQL type for a Databricks adapter during column-type rendering.

Common situations: Rendering a Databricks model's schema/column types (e.g. building DDL or a `describe` result) and hitting `field_to_string`; a developer adding Databricks support who has not yet defined its metadata SQL-type key.

Related errors

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