Anyone seen this before?

target-postgres

is failing because it can’t drop a target table that is being used in a downstream dbt view.

target-postgres       | psycopg2.errors.DependentObjectsStillExist: cannot drop table tap_mongodb.foobar__old because other objects depend on it
target-postgres       | DETAIL:  view analytics.stg_foobar depends on table tap_mongodb.foobar__old
target-postgres       | HINT:  Use DROP ... CASCADE to drop the dependent objects too.
target-postgres       | 
target-postgres       | CRITICAL ('foobar - Exception activating table version 1617612127282', DependentObjectsStillExist('cannot drop table tap_mongodb.foobar__old because other objects depend on it\nDETAIL:  view analytics.stg_foobar depends on table tap_mongodb.foobar__old\nHINT:  Use DROP ... CASCADE to drop the dependent objects too.\n'))

Haven’t run into this in postgres, but it sounds suspiciously similar to this redshift phenomenon that can be solved via late-binding views in DBT: https://blog.getdbt.com/using-redshift-s-late-binding-views-with-dbt/

Ah, interesting. Certainly worth a try. It’s indeed weird to see this with postgres.

huh, bummer - that IS weird

I need to get up to speed with the latest dbt config options (my mental model is a couple versions behind). But this may also be something on the

datamill-co/target-postgres

side, as the staging of temporary tables should probably use

DROP … CASCADE

, I would imagine.

I had an issue where a table had dependencies (not from DBT, so this might not help), and I used the target-postgres

before_run_sql

and

after_run_sql

to drop and recreate stuff around the process.

Yeah I was thinking that. Seems not ideal.