Changes to dispatch in dbt v0.20

As promised, what follows is effectively the same as calogica/dbt-expectations#78.

Required code change

We've made a change to adapter.dispatch: Instead of passing a _get_namespaces() macro to the packages arg, you should pass the name of this package (as a string) to the macro_namespace arg, which is now the second positional argument.

In practice, this just looks like switching each macro like:

dbt-date/macros/calendar_date/date_part.sql

Lines 1 to 3 in 370d472

    
           {% macro date_part(datepart, date) -%} 
        
               {{ adapter.dispatch('date_part', packages = dbt_date._get_utils_namespaces()) (datepart, date) }} 
        
           {%- endmacro %}

To:

{% macro date_part(datepart, date) -%}
      {{ adapter.dispatch('date_part', 'dbt_date') (datepart, date) }}
{%- endmacro %}

I hope this could be as simple as Find + Replace for packages = dbt_date._get_utils_namespaces() → 'dbt_date'. If you prefer more explicit syntax, you could also make this:

{% macro date_part(datepart, date) -%}
      {{ adapter.dispatch(macro_name = 'date_part', macro_namespace = 'dbt_date') (datepart, date) }}
{%- endmacro %}

For the README

If a user wishes to override/shim this package, instead of defining a var named dbt_expectations_dispatch_list (or dbt_utils_dispatch_list), they should now define a config in dbt_project.yml, for instance:

dispatch:
  - macro_namespace: dbt_date
    search_order: ['my_project', 'dbt_date']  # enable override
  - macro_namespace: dbt_utils
    search_order: ['spark_utils', 'dbt_utils']  # shim for spark

Notes

This change is in dbt v0.19.2 as well. Both v0.19.2 and v0.20.0 have backwards compatibility for the old syntax, so there's no huge rush to upgrade. The old syntax will start raising a deprecation warning in v0.20. As soon as you do upgrade to the new syntax, you'll need to require dbt >= 0.19.2 (or just >=0.20.0, for simplicity, since you're already making compatibility changes in #69).

See also:

@jtcohen6 getting a weird test failure on 1 out of a few tests using dbt 0.20.0rc1 . Even though this integration tests returns (based on the test SQL from the logs)

| failures | should_warn | should_error |
|----------|-------------|--------------|
| 0        | false       | false        |

the CLI reports

Failure in test dbt_utils_expression_is_true_test_dates_time_stamp_dbt_date_from_unixtimestamp_unix_epoch_ (models/test_dates.yml)
  Got 2 results, configured to fail if != 0

This is only one where that's the case and I can't figure out why. Any ideas?

This is a very simple config and exactly the same as other tests in this file:

        - dbt_utils.expression_is_true:
            expression: "time_stamp = {{ dbt_date.from_unixtimestamp('unix_epoch') }}"

(I'm using the 0.20 compat branch of dbt-utils)

This is the relevant query from the logs:

select
      count(*) as failures,
      count(*) != 0 as should_warn,
      count(*) != 0 as should_error
    from (
      with meet_condition as (

    select * from postgres.dbt_date_integration_tests.test_dates where 1=1

),
validation_errors as (

    select
        *
    from meet_condition
    
    where not(time_stamp = to_timestamp(unix_epoch))

)

select *
from validation_errors


      
    ) dbt_internal_test

which when run through postgres, returns

| failures | should_warn | should_error |
|----------|-------------|--------------|
| 0        | false       | false        |

Very weird! I don't know why it would say 2 when the test query is clearly returning failures: 0.

I'm planning to release dbt-utils 0.7.0 today, which will be 0.20 compatible. If you can open up a PR with dbt v0.20 / dbt-utils v0.7 compatibility, I can take it for a spin.

	{% macro date_part(datepart, date) -%}
	{{ adapter.dispatch('date_part', packages = dbt_date._get_utils_namespaces()) (datepart, date) }}
	{%- endmacro %}