support custom schemas

[dlawin]

Resolves #404

Adds support for custom schemas, with a new data_diff var
Example (custom schema environments):

vars:
  data_diff:
    prod_schema: BEERS
    prod_database: INTEGRATION

No need to do anything here, custom_schemas is assumed to be True
prod path = <prod_database>.<prod_schema>_<custom_schema>.<model> if the model has a custom schema.
else:
prod path = <prod_database>.<prod_schema>.<model>

Setting custom_schemas: False would cause the prod comparison path to be <prod_database>.<prod_schema>.<model> or <prod_database>.<same_schema_as_dev_model>.<model> based on the existence of the prod_schema variable (existing behavior).

Example (schema environments):

    prod_schema: BEERS
    prod_database: INTEGRATION
    custom_schemas: False

prod path = <prod_database>.<prod_schema>.<model>

Example (database environments):

    prod_database: INTEGRATION
    custom_schemas: False

prod path = <prod_database>.<same_schema_as_dev_model>.<model>

[kylemcnair]

@dlawin Under what scenario would a user set custom_schema: false? Assuming I'm following this, that seems like it would be unexpected behavior?

This requires a new data_diff var

Does it make sense to set this to default true, and allow users to set it false if desired? I think keeping required vars to a minimum would be ideal. ie, you'd only add custom_schema if you wanted to override the default of true.

[dlawin]

@dlawin Under what scenario would a user set custom_schema: false? Assuming I'm following this, that seems like it would be unexpected behavior?

This requires a new data_diff var

Does it make sense to set this to default true, and allow users to set it false if desired? I think keeping required vars to a minimum would be ideal. ie, you'd only add custom_schema if you wanted to override the default of true.

I like that, maybe having the variable be disable_custom_schemas. Set that to true if you don't want the out of the box behavior

[kylemcnair]

@dlawin Under what scenario would a user set custom_schema: false? Assuming I'm following this, that seems like it would be unexpected behavior?

This requires a new data_diff var

Does it make sense to set this to default true, and allow users to set it false if desired? I think keeping required vars to a minimum would be ideal. ie, you'd only add custom_schema if you wanted to override the default of true.

I like that, maybe having the variable be disable_custom_schemas. Set that to true if you don't want the out of the box behavior

Me gusta. That way users don't have to think about whether their project uses custom schemas or not, data-diff --dbt will just work

[dlawin]

@dlawin Under what scenario would a user set custom_schema: false? Assuming I'm following this, that seems like it would be unexpected behavior?

This requires a new data_diff var

Does it make sense to set this to default true, and allow users to set it false if desired? I think keeping required vars to a minimum would be ideal. ie, you'd only add custom_schema if you wanted to override the default of true.

I like that, maybe having the variable be disable_custom_schemas. Set that to true if you don't want the out of the box behavior

Me gusta. That way users don't have to think about whether their project uses custom schemas or not, data-diff --dbt will just work

Updated the description

[williebsweet]

As a rule of thumb - I think we should stay away from asserting on a negative (it can be confusing). Disable = True is asserting on a negative.

@dlawin Can we reformat to custom_schemas: T/F?

[dlawin]

As a rule of thumb - I think we should stay away from asserting on a negative (it can be confusing). Disable = True is asserting on a negative.

@dlawin Can we reformat to custom_schemas: T/F?

fixed, I overthought what kyle suggested lol