Support transient tables on Snowflake

[drewbanin]

Closes #946

This PR adds support for transient tables on Snowflake using the transient config. Example usage:

# dbt_project.yml

models:
  transient: true

By default, models will be created as "transient". If users wish, they can override the setting to be false, which will cause these tables to participate in Snowflake's Time Travel mechanism.

In addition to adding the transient config, I also ripped adapter-specific configs out of the SourceConfig class. These configs are now supplied by adapters. I think this is probably a good idea, but I'm unsure how sound my implementation is. Super open to tweaking things to make this fit nicely into the adapter plugin architecture :)

[beckjake]

This looks good, I like the adapter-specific configs. One thing I found surprising in here was the lack of cluster_by/partition_by for bigquery. Is that because we only allow those fields in config blocks, or something?

[beckjake]

Maybe this (and redshift/snowflake's versions of this) should be a frozenset to avoid any mutability issues?

[drewbanin]

yeah, that's a good idea, i will update

[beckjake]

This seems to mean that adapter specific configurations will always be clobber-only. If we wanted to change that in the future, would it be easy/possible without breaking existing adapters?

[drewbanin]

I gave this a tiny bit of thought, and I'm really not sure what an append/extend config could possibly look like for adapter configs. I think "clobber" will be the most common paradigm for new configs, but I do also like the idea of not needing to change this API in the future. I think it will be easy to just add a couple more class attributes like AdapterSpecificExtendConfigs as the need arises, and 3rd party adapters should just inherit these attributes from the base adapter. Do you buy that? Or do you think there's a better way of doing this?

[beckjake]

Yeah, that does sound ok, in the worst case we end up with 6 of these which isn't terrible.

I do think adapter-specific append configs are potentially pretty reasonable - as a lazy example, imagine an adapter where the underlying database supports a concept like tags. It would feel pretty natural for those to append instead of clobbering.

[drewbanin]

This looks good, I like the adapter-specific configs. One thing I found surprising in here was the lack of cluster_by/partition_by for bigquery. Is that because we only allow those fields in config blocks, or something?

Really, really good point! I think this was probably an oversight when we initially added those configs, and I believe that they won't work if defined in dbt_project.yml at present. I can fix this as a part of this change for sure.

[drewbanin]

@beckjake no rush, but 🏓 when you're ready!

[beckjake]

lgtm!

[jon-rtr]

This is awesome! Thank you all.