Dbt: minimize downtime for incremental models with full-refresh

[drewbanin]

incremental models should:

1. build
2. drop
3. rename

0.8.3 and 0.9.0a1 instead do drop, build, rename, leading to a potentially significant amount of time during which the model is unavailable for querying

[igrayson]

Should this be labeled as a bug? As of 0.8.3, the new behavior no longer matches our docs @ https://dbt.readme.io/v0.8/reference#section-refresh-incremental-models ; specifically, --full-refresh doesn't cause dbt to treat models as table models (table models continue to have the desired behavior of build/drop/rename in 0.8.3).

If you provide the --full-refresh argument to dbt run, dbt will treat incremental models as table models.

This also means that 0.8.3+ users can temporarily configure an incremental model with materialized: table to get a working --full-refresh semantic.

[drewbanin]

Thanks @igrayson

[drewbanin]

see also: https://github.com/fishtown-analytics/dbt/issues/653

[drewbanin]

The 0.13.x/0.14.0 implementation of incremental models for redshift/postgres is not transactionally consistent if an error occurs in an incremental model in --full-refresh mode. We should try to fix that at the same time we make minimize the incremental downtime for rebuilds