Fix get_table_types for bigquery and databricks materialized view and streaming table

[davehowell]

resolves #
#881
#861

Includes (corrected) fix from #862

Problem

I reproduce this bug using the dbt-codegen package, which in turn calls this dbt-utils package. Specifically I was trying to run dbt run-operation generate_source --args '{"table_pattern": "%_raw"}'

This ends up calling dbt_utils.get_relations_by_pattern which calls dbt_utils.get_tables_by_pattern_sql to fetch metadata from information_schema and then passes it to api.Relation.create() which then throws the error

Invalid relation type: materializedview

Solution

The dbt-databricks adapter uses DatabricksRelationType, see: https://github.com/databricks/dbt-databricks/blob/25caa2a14ed0535f08f6fd92e29b39df1f453e4d/dbt/adapters/databricks/relation.py#L40

The dbt-bigquery adapter uses the base RelationType, see: https://github.com/dbt-labs/dbt-adapters/blob/e966f0ddea91ae531d92e703696bb80144e5b28e/dbt-bigquery/src/dbt/adapters/bigquery/relation.py#L13

and where it is used: https://github.com/dbt-labs/dbt-adapters/blob/e966f0ddea91ae531d92e703696bb80144e5b28e/dbt-adapters/src/dbt/adapters/contracts/relation.py#L20

Also see the databricks table_types documented here https://docs.databricks.com/aws/en/sql/language-manual/information-schema/tables#table-types

This PR is a very small fix, and I have verified it works on my own dbt projects by monkey-patching it with a file ./macros/get_table_types_sql.sql with the contents as per this PR

Checklist

• This code is associated with an issue which has been triaged and accepted for development.
• I have read the contributing guide and understand what's expected of me
• I have run this code in development and it appears to resolve the stated issue
• This PR includes tests, or tests are not required/relevant for this PR

There are pre-existing tests for this macro, this PR is for a bug, not new functionality.

• I have updated the README.md (if applicable)
  Not applicable, because functionality doesn't vary from the documented intention

[b-per]

Thanks for the PR! The fix for Databricks looks correct — MATERIALIZED_VIEW (underscore) is indeed what Databricks returns in information_schema.tables, and materialized_view matches DatabricksRelationType.

However, I think the new bigquery__get_table_types_sql dispatch isn't needed. The simpler fix is to update the default dispatch (and the Postgres one) to output materialized_view instead of materializedview. The default already handles BigQuery's 'MATERIALIZED VIEW' (with space) input correctly — it just had the wrong output value.

So the suggestion would be:

• Keep the Databricks changes (input match fix + STREAMING_TABLE)
• Drop the new bigquery__get_table_types_sql macro
• Update default__get_table_types_sql and postgres__get_table_types_sql to output materialized_view instead of materializedview

For context: materializedview was never a valid RelationType value. The macro was created in Feb 2022 (dbt-utils 0.8.1) before the RelationType.MaterializedView enum existed. When the enum was added to dbt-core in June 2023 (PR #7239), it used materialized_view (with underscore), but dbt-utils was never updated to match. There was actually a commit (fbd295e) that fixed this, but it landed on a next/patch branch that was never merged to main.

[davehowell]

@b-per Thank you for the review and suggestions. I agree your suggestions are better! I have pushed those changes so would appreciate the re-review.

I did start to change the default dispatch but I wasn't sure about the impact of modifying that would have on a bunch of other targets so I went with the more cautious BigQuery-only approach. I also wasn't sure about Postgres but have made that change too as you suggested.