Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[CT-3330] [Bug] get_create_materialized_view_as_sql is missing from Postgres 1.7 runtime in Cloud #9016

Closed
2 tasks done
VersusFacit opened this issue Nov 6, 2023 · 1 comment · Fixed by #9021
Closed
2 tasks done
Assignees
Labels
backport 1.7.latest bug Something isn't working High Severity bug with significant impact that should be resolved in a reasonable timeframe regression

Comments

@VersusFacit
Copy link
Contributor

VersusFacit commented Nov 6, 2023

Is this a new bug in dbt-core?

  • I believe this is a new bug in dbt-core
  • I have searched the existing issues, and I could not find an existing issue for this bug

Current Behavior

1.6 added Postgres support for materialized views. While 1.7 saw some ergonomic upgrades across the board, the previously working materialized views flow now can struggle to locate a default macro needed for this materalization.

The kicker is that this is a Cloud-only bug we're detecting. This bug is found only in Cloud, neither in CI/CD nor local tests in core.

Is this a caching problem? A macro space problem? Who's to say?

Expected Behavior

Materialized views build successfully (just as they do outside of core).

Steps To Reproduce

  1. Set the dbt env to 1.7.latest
  2. Open the IDE to a simple project in Cloud (e.g. one obtained from a dbt init)
  3. In the my_second_dbt_model.sql, simple convert the materialization from table to materialized_view.
  4. dbt run -s +my_second_dbt_model

Relevant log output

Compilation Error in model my_second_dbt_model (models/example/my_second_dbt_model.sql) `get_create_materialized_view_as_sql` has not been implemented for this adapter.
> in macro default__get_create_materialized_view_as_sql (macros/relations/materialized_view/create.sql)
> called by macro get_create_materialized_view_as_sql (macros/relations/materialized_view/create.sql)
> called by macro materialized_view_get_build_sql (macros/materializations/models/materialized_view.sql)
> called by macro materialization_materialized_view_default (macros/materializations/models/materialized_view.sql)
> called by model my_second_dbt_model (models/example/my_second_dbt_model.sql)

Environment

Cloud with dbt-core 1.7. Postgres Managed with SSH.

Which database adapter are you using with dbt?

postgres

Additional Context

I verified by hand materialized views are building just fine for other adapters, so this is a postgres-specific problem.

We also note that this works with postgres + 1.6 in Cloud.

One other piece of info is that the macro in question was moved (not altered, just moved). Whether this impacts the runtime or not is yet to be seen.

@VersusFacit VersusFacit added bug Something isn't working triage labels Nov 6, 2023
@github-actions github-actions bot changed the title [Bug] get_create_materialized_view_as_sql is missing from Postgres 1.7 runtime [CT-3330] [Bug] get_create_materialized_view_as_sql is missing from Postgres 1.7 runtime Nov 6, 2023
@VersusFacit VersusFacit changed the title [CT-3330] [Bug] get_create_materialized_view_as_sql is missing from Postgres 1.7 runtime [CT-3330] [Bug] get_create_materialized_view_as_sql is missing from Postgres 1.7 runtime in Cloud Nov 6, 2023
@dbeatty10 dbeatty10 removed the triage label Nov 7, 2023
@VersusFacit
Copy link
Contributor Author

Update from @mikealfare

The issue is here: https://github.com/dbt-labs/dbt-core/blob/main/plugins/postgres/setup.py#L63-L70 (plus no MANIFEST.in file). We don't actually package up the macros recursively and I moved them one level deeper in 1.7. We don't catch it in CI because we pull the entire repo and so the macros come along with it. However, when we build we drop these files. dbt-postgres 1.7 is likely broken on PyPI, which then gets installed in the bundle.

@graciegoheen graciegoheen added Highest Severity critical bug that must be resolved immediately High Severity bug with significant impact that should be resolved in a reasonable timeframe and removed Highest Severity critical bug that must be resolved immediately High Severity bug with significant impact that should be resolved in a reasonable timeframe labels Nov 7, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backport 1.7.latest bug Something isn't working High Severity bug with significant impact that should be resolved in a reasonable timeframe regression
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants