redundant to include incremental materialization

[dataders]

Marie Kondo inspo... if it works with the global project, why not just rely on that? This was we automatically inherit upgrades. The downside is that we'll have to accommodate any breaking changes, but we can always re-implement at that time?

[mikaelene]

I guess it was there for a reason, but maybe the global_project adjusted along the way. @jtcohen6 how well are incremental materialisations tested in the adapter-tests pytest package?

But it really looks like it works. It is always better to relay on the global_project, so I am leaning to that there are no reasons to not make this merge...

[jtcohen6]

Definitely in favor of this! The less code, the less surface area, the better. If you need to reimplement/override because of breaking changes in a future release, so be it. (And hopefully you'd be able to test the beta/RC and find it first, so we can rewrite the SQL in a T-SQL-friendlier way.)

The test_dbt_incremental sequence is pretty good, but I believe it tests append-only behavior (i.e. an incremental model without unique_key). I'd just say, you should sure it works right with a unique_key as well.

[dataders]

@mikaelene this is ready to be merged!

[mikaelene]

@swanderz do you want to add anything in the changeling for this? You can add it in master-branch if you don't want to reopen this.

[dataders]

@mikaelene thanks for the heads up! I merged #106 to do exactly that. We're ready for a v0.19.0.1 release now I think.