You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, all stg and int models are materialized in the database. This clutters the schema and is not desirable for production analytic use cases. However, developers (and analysts in some cases) may want/need to inspect the contents of these models.
We can use a dbt_project variable that users pass into the command line that will enable materialization of stg and int models (I think it should be disabled by default).
The text was updated successfully, but these errors were encountered:
I've tried this before and the solution that we used was to instead have a post run hook or a macro that drops all objects except the core tables we want i.e. the final OMOP tables.
At the moment our final dbt_synthea_dev schema holds 85 tables. We could rationalize those to be views instead? This may have a performance hit downstream.
Another approach would be to have our OMOP models be in their own schema - but I am unsure if that's really better // its just more complex
Currently, all stg and int models are materialized in the database. This clutters the schema and is not desirable for production analytic use cases. However, developers (and analysts in some cases) may want/need to inspect the contents of these models.
We can use a dbt_project variable that users pass into the command line that will enable materialization of stg and int models (I think it should be disabled by default).
The text was updated successfully, but these errors were encountered: