Different target environments - workaround

[sisu-callum]

When trying to figure out how I'd create the LookML files for production environments as opposed to development, I realized that this process is built off the artifacts. So all you need to do is overwrite the artifacts with the correct information and then re-run. This workaround is dbt docs generate --target production and then run dbt2looker. It creates the LookML that references the right DB's and Schema's.

This still introduces issues when creating new models that are not materialized in the production environment. I wonder if there is a better way to parse through the manifest and then replace the schema and database references. The issue is that these are generated at runtime in dbt. So not sure how to best handle this one.

[owlas]

Hey @sisu-callum - this is a great idea! I hadn't thought about it. The reason we need the materialised views is to get all the column types (we can substitute the database and table in prod no problem).

But actually when pushing to production, we should already have locked in these types when materialising the dev tables.

I'm thinking either:

• We live with the work around dbt run --target production && dbt docs generate --target production && dbt2looker
• Or we come up with a lighter "prod" run that takes a lot of the templated lookml from the most recent "dev" run

Not sure what that second option would look like yet