dbt-labs/dbt-core · error

Oracle

Error message

Oracle

What it means

This is a Rust `todo!()` panic: the `get_relation` dispatcher has `todo!("Oracle")` because Oracle relation lookup is not implemented yet. Any relation resolution with an Oracle adapter panics with the message 'Oracle'. It indicates an incomplete adapter, not a database error.

Source

Thrown at crates/dbt-adapter/src/metadata/get_relation.rs:87

            spark_get_relation(adapter, state, ctx, conn, schema, identifier, token)
        }
        AdapterType::DuckDB | AdapterType::LakeCompute => duckdb_get_relation(
            adapter, state, ctx, conn, database, schema, identifier, token,
        ),
        AdapterType::Fabric => fabric_get_relation(
            adapter, state, ctx, conn, database, schema, identifier, token,
        ),
        AdapterType::ClickHouse => clickhouse_get_relation(
            adapter, state, ctx, conn, database, schema, identifier, token,
        ),
        AdapterType::Exasol => exasol_get_relation(
            adapter, state, ctx, conn, database, schema, identifier, token,
        ),
        AdapterType::Starburst => todo!("Starburst"),
        AdapterType::Athena => todo!("Athena"),
        AdapterType::Trino => todo!("Trino"),
        AdapterType::Dremio => todo!("Dremio"),
        AdapterType::Oracle => todo!("Oracle"),
        AdapterType::Datafusion => todo!("Datafusion"),
    }
}

/// Parses an `INFORMATION_SCHEMA.ROUTINES`-shaped result batch into a
/// [`Relation`].
pub(crate) fn relation_from_routines_batch(
    adapter: &AdapterImpl,
    database: &str,
    schema: &str,
    identifier: &str,
    batch: &arrow::record_batch::RecordBatch,
) -> AdapterResult<Option<Relation>> {
    if batch.num_rows() == 0 {
        return Ok(None);
    }

    let column = batch.column_by_name("table_type").unwrap();

View on GitHub (pinned to 0267ce9170)

Solutions

1. Switch to an adapter type with implemented metadata lookup until Oracle support lands
2. Implement oracle_get_relation querying ALL_TAB_COLUMNS/ALL_OBJECTS or the adapter's INFORMATION_SCHEMA bridge and wire it into the match
3. Pin a dbt-adapter version where the Oracle arm is implemented
4. Validate adapter capabilities at startup so unimplemented adapters are rejected with a clear message

Example fix

// before
AdapterType::Oracle => todo!("Oracle"),
// after
AdapterType::Oracle => oracle_get_relation(
    adapter, state, ctx, conn, database, schema, identifier, token,
),

if adapter_type == AdapterType::Oracle {
    return Err("Oracle get_relation is unimplemented in this version".into());
}

fn oracle_ready(t: &AdapterType) -> bool { !matches!(t, AdapterType::Oracle) }

let ok = std::panic::catch_unwind(|| get_relation(...));
if let Err(_) = ok { return Err(AdapterError::NotImplemented("Oracle get_relation")); }

When it happens

Trigger: Calling `get_relation` (public) with AdapterType::Oracle; the arm at crates/dbt-adapter/src/metadata/get_relation.rs:87 executes `todo!("Oracle")`.

Common situations: Running dbt against an Oracle Database (on-prem or Autonomous DB) while the Oracle adapter is still stubbed in dbt-adapter; the panic occurs the first time dbt checks whether a relation exists.

Related errors

• load_dataframe() for the Salesforce adapter
• Starburst
• Athena
• Trino
• Dremio

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