Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add null value coalescing options to
MetricInputMeasure
protocol #159Add null value coalescing options to
MetricInputMeasure
protocol #159Changes from all commits
9878f5e
b37c967
f817bfe
98c13ca
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this should eventually be expanded to allow floats, since measures can be averages and things like that. Oddly enough, the
float
type also allows int types, but the reverse is not true: https://peps.python.org/pep-0484/#the-numeric-towerHowever, it's annoying, because we don't want to render SQL like
COALESCE(average_revenue, 0.0000000000017)
or whatever.Perhaps we should return
Optional[Union[int, float]]
and then explicitly check at the callsite, since how we format the value into the SQL might be different depending on whether it's an int or a float.We can leave this as-is for now, since widening the type is backwards compatible and by far the most common fallback value will be 0, but if we already know int | float is what we want we might as well get that rolling now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm gonna update it now to support both, that is
Optional[Union[int, float]]
so that we have less work to do in the future. I think this means I'll also have to update it in core, but eh oh well.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So I looked into this aaaaand there's some wonkiness. JsonSchema has two types for numerics,
number
andinteger
. The interesting part isnumber
will handle both integers and floats, whereasinteger
only handle integers. Thus making it seem like the solution on the JsonSchema side would be to specifyfill_nulls_with
asnumber
. The problem though is on the python/pydantic side. If you specifyUnion[float, int]
it is always parsed as a float. If you specify it asUnion[int, float]
, it'll always parse as an int. I'm not entirely sure if this is a python issue or a pydantic issue. There are some possible ways around it, but it'll require a fair amount of extra work. The truth is most people will be setting this to 0, or possibly 1. If someone ends up needing this to be a float, we'll address it then.