1.0.0

Version 1.0.0

This release is a significant overhaul of dbt Constraints to support some key requested features.

What's Changed

• The package now supports both RELY and NORELY constraints on Snowflake. This has opened up a lot more possibilities that were previously blocked because previously we only created RELY constraints for join elimination. Now that the code can create constraints that Snowflake will not try to use for join elimination, we can safely create constraints when tests have not be executed.
• The previous logic looped over dbt's results object and created constraints for passed tests. Now the logic loops over all the tests in dbt's graph object that contains all the metadata for the project, and then it has a series of checks to determine if each test should be created as a RELY or NORELY constraint. The README.md describes all the conditions but essentially we determine if a test or its model was "selected" and whether the test passed, failed, or was skipped.
• The always_create_constraint feature has taken on a more significant role. Previously it didn't do very much because it only skipped a few of the criteria used to pick constraints to generate. Now, this is the parameter that will trigger constraints to be generated even if a test was not executed. For example, you can run dbt run and all the tests associated with your models will be used to create NORELY constraints. Later if you run dbt test, all of those constraints will be turned into RELY constraints if the test passes.
• Another previous issue was that a constraint could be created with the RELY property and then subsequently, the test could fail and the RELY property was not changed. Now every execution of a test could also cause the constraint to be altered to RELY or NORELY.

Full Changelog: 0.6.3...1.0.0