-
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
Handle no-metric queries with sub-daily metric_time
#1359
Handle no-metric queries with sub-daily metric_time
#1359
Conversation
398c5dc
to
2a3a284
Compare
metric_time
22a7253
to
11058a5
Compare
88dbe8b
to
fdcf983
Compare
a294e89
to
40b1db3
Compare
e63dfca
to
eb31d9f
Compare
40b1db3
to
2231f38
Compare
b12aebb
to
b1ec4d6
Compare
79e46c6
to
d5cff0a
Compare
b1ec4d6
to
2ef8de8
Compare
Use time spines to determine granularity options and default to DAY for metric_time.
Also removes some CLI snapshot output that was accidentally added due to a print statemen
d5cff0a
to
e984404
Compare
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.
There's a snapshot change I don't understand but if that's expected this seems ok.
I think we probably need to streamline how we handle all of these granularity locations. The TimeDimension granularity specification is quite confusing in this new world where it only fixes a minimum.
element_name=self.element_name, | ||
time_granularity=self.time_granularity, | ||
date_part=self.date_part, | ||
entity_links=(), |
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.
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.
Your PR comment gifs are always the best.
satisfiable_metric_time_specs = set(needed_linkable_specs).intersection( | ||
set(linkable_specs_in_right_node) | ||
) |
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.
Ah ok. I think this helps with custom calendar, too, since it'll pull all the extra granularity columns.
@@ -332,7 +332,7 @@ def _build_time_dimension_instances_and_columns( | |||
) -> Tuple[List[TimeDimensionInstance], List[SqlSelectColumn]]: | |||
time_dimension_instances: List[TimeDimensionInstance] = [] | |||
select_columns: List[SqlSelectColumn] = [] | |||
# Add time dimensions with a smaller granularity for ease in query resolution | |||
# Add time dimensions with a larger granularity for ease in query resolution |
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.
😂
) | ||
# If querying metric_time without metrics, will query from time spines. | ||
# Defaults to DAY granularity if available in time spines, else smallest available granularity. | ||
min_time_spine_granularity = min(self._time_spine_sources.keys()) |
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 default is because the time_spine_sources automatically include the DAY granularity (via TimeSpineSource.create_from_manifest()
) if no custom time spines are found, correct?
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 default is set so that if you query ambiguous metric_time
without metrics, we don't return nanoseconds if you have that time spine configured. Since metric_time
defaults to DAY
in all other scenarios (unless overridden by the metric's default granularity), this seemed like the expected behavior.
@@ -419,7 +419,6 @@ | |||
'lux_listing__listing__lux_listing__twice_bookings_fill_nulls_with_0_without_time_spine', | |||
'lux_listing__listing__lux_listing__views', | |||
'lux_listing__listing__lux_listing__views_times_booking_value', | |||
'metric_time__day', |
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.
Wait, is this expected?
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 had the same question and meant to leave a comment explaining but I forgot.
This test is specifically filtering out specs with the property DERIVED_TIME_GRANULARITY
. I'm not sure why. But I made a change in this PR that makes all metric_time
granularities derived for no-metric queries.
Debatable which behavior would be expected for that property here, but doesn't seem super important since it's only internal.
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 could've sworn I approved this before lunch but apparently hunger was making me delusional....
Makes some updates to enable no-metric queries with sub-daily time dimensions and adds integration tests for those queries.