Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Multiple metrics macro does not include results when dimension has NULL values

See original GitHub issue

Is this a new bug in dbt_metrics?

I believe this is a new bug in dbt_metrics
I have searched the existing issues, and I could not find an existing issue for this bug

Current Behavior

It looks like there is a issue when grouping metrics by dimensions with NULL values. I have a dimension that in certain case has NULL value, and when I use the macro for multiple metrics including this dimension the output does not include the rows where this dimension is NULL and the metric value is greater than zero.

Expected Behavior

In the output of the model, I would expect to have a row that include metrics value also when the dimension is NULL.

Steps To Reproduce

fix

Relevant log output

No response

Environment

- dbt-adapter & version:
- dbt_metrics version:

Which database adapter are you using with dbt?

snowflake

Additional Context

No response

Issue Analytics

State:
Created a year ago
Comments:8

Top GitHub Comments

2reactions

callum-mcdatacommented, Sep 23, 2022

Ah - I see what you all mean. This is because the using clause is not a NULL-Safe operator, which means that it doesn’t match nulls. I’ll be completely honest - I am against changing the default join behavior to a Null-Safe operator because of the number of edge cases that it could cause to fail silently.

My suggested workaround would be to override NULL columns in the dimension in question in to some known quantity. It looks like country was provided as one of the dimensions included. I’d suggest altering the model this metric is built upon with the following logic:

ifnull(country, 'no country provided') as country

That should resolve your issue and ensure that the join logic remains consistent regardless of the behavior of the underlying columns.

Does that solution work for you both?

0reactions

clairetaylor352commented, Oct 25, 2022

Because it’s already a widely used model across our warehouse, and our convention is generally that NULL means not set so changing the column would break with that convention. Basically changing the field would not be an option. Adding a new field would, but would feel like a hack.