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
We use a custom generate_schema_name macro for our models. I have been unable to figure out how to duplicate this logic for where it should attempt to place the masking policy. When our ADO pipelines for new PRs are running, it doesn't seem to be able to determine the correct schema to place it in. I can either hard code it using the common schema name variable. Or I can leave it to place it in every schema that a model uses.
In this case, the use common masking policy schema is technically variable. When local dev / PRs (which we use a target.name to determine if it's a PR) then use the default schema. When it's our dev/sandbox/prod dbt environments, use a common schema.
The purpose for this is that we want to use a common schema (I don't need 30 copies of a masking policy in each schema where a model uses them that are all identical), but we don't want people's development creating objects in the "real" schemas either.
The text was updated successfully, but these errors were encountered:
@mjahammel I don't believe that would work for our case since our macro has a couple inputs and when I tried to call it, it would tell me that the variables weren't populated.
Beginning of the macro definition
{% macro generate_schema_name(custom_schema_name, node) -%}
We use a custom generate_schema_name macro for our models. I have been unable to figure out how to duplicate this logic for where it should attempt to place the masking policy. When our ADO pipelines for new PRs are running, it doesn't seem to be able to determine the correct schema to place it in. I can either hard code it using the common schema name variable. Or I can leave it to place it in every schema that a model uses.
In this case, the use common masking policy schema is technically variable. When local dev / PRs (which we use a target.name to determine if it's a PR) then use the default schema. When it's our dev/sandbox/prod dbt environments, use a common schema.
The purpose for this is that we want to use a common schema (I don't need 30 copies of a masking policy in each schema where a model uses them that are all identical), but we don't want people's development creating objects in the "real" schemas either.
The text was updated successfully, but these errors were encountered: