-
Notifications
You must be signed in to change notification settings - Fork 98
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
Bug fix: For measures using join_to_timespine
, apply filters after time spine join
#1056
Conversation
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.
This looks good, the inline is just me double-checking that we're rendering faithfully even if the input might be odd.
metric_time__day BETWEEN '2020-01-03' AND '2020-01-05' | ||
) AND ( | ||
metric_time__day > '2020-01-01' | ||
) |
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.
This is just an artifact of passing both a time constraint and a where filter on metric_time in the same query, right? Because if the filter in the query was metric_time__day = '2020-01-01'
then this would return the empty set, but that's actually what the constraint combination would tell us to do.
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.
Yes. I knew it was weird when I wrote this test case but I just wanted to make sure both filters got rendered 😆
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.
But also it won't return an empty dataset since '2020-01-03'
through '2020-01-05'
is > '2020-01-01'
!
Resolves #1039
Completes SL-1732
Description
For queries using measures that join to time spine, filters were being applied before the time spine join, but not after. This means that there might be additional rows added from the time spine join that should be removed by the filters, resulting in unexpected rows in the output data. Here, we update the DataFlow Plan to apply those filters again after the time spine join, ensuring there will be no unexpected rows in the result.
Note: this means the filters are applied multiple times, which is redundant for the final output but ideally results in a more efficient query.