trakshan-mishra commented on code in PR #44526:
URL: https://github.com/apache/superset/pull/44526#discussion_r4124545252
##########
superset/common/query_context_factory.py:
##########
@@ -275,6 +275,27 @@ def _apply_granularity( # noqa: C901
query_object.granularity = main_dttm_col
return
+ # A ``query_context`` saved by an older version carries no
+ # ``granularity`` of its own and no x-axis at all: its temporal column
+ # survives only in ``form_data`` as ``granularity_sqla``. Explore
+ # rebuilds the query from ``form_data`` on every render and never
+ # notices, but every other consumer replays the stored query verbatim
+ # and fails the ``not granularity and is_timeseries`` check in
+ # ``models.helpers``. The absent x-axis is what distinguishes this
shape
+ # from a modern chart, so it is tested first. Recover the column the
way
+ # Explore effectively does, preferring what the chart saved over the
+ # dataset default.
+ if (
+ not x_axis
+ and query_object.granularity is None
+ and query_object.is_timeseries
+ ):
+ legacy_granularity = (form_data or {}).get("granularity_sqla") or
getattr(
+ datasource, "main_dttm_col", None
+ )
+ if legacy_granularity in temporal_columns:
+ query_object.granularity = legacy_granularity
Review Comment:
Fixed in 6216ac9. An adhoc `granularity_sqla` is now reduced to its
`sqlExpression` before the membership test against `temporal_columns`, so it
resolves instead of raising "unhashable type: 'dict'". Covered by
`test_apply_granularity_legacy_adhoc_granularity_sqla`.
##########
superset/common/query_context_factory.py:
##########
@@ -275,6 +275,27 @@ def _apply_granularity( # noqa: C901
query_object.granularity = main_dttm_col
return
+ # A ``query_context`` saved by an older version carries no
+ # ``granularity`` of its own and no x-axis at all: its temporal column
+ # survives only in ``form_data`` as ``granularity_sqla``. Explore
+ # rebuilds the query from ``form_data`` on every render and never
+ # notices, but every other consumer replays the stored query verbatim
+ # and fails the ``not granularity and is_timeseries`` check in
+ # ``models.helpers``. The absent x-axis is what distinguishes this
shape
+ # from a modern chart, so it is tested first. Recover the column the
way
+ # Explore effectively does, preferring what the chart saved over the
+ # dataset default.
+ if (
+ not x_axis
+ and query_object.granularity is None
+ and query_object.is_timeseries
+ ):
+ legacy_granularity = (form_data or {}).get("granularity_sqla") or
getattr(
+ datasource, "main_dttm_col", None
+ )
+ if legacy_granularity in temporal_columns:
+ query_object.granularity = legacy_granularity
Review Comment:
I checked this against the full query path, and the restriction isn't
dropped.
When a query has no `time_range`, `QueryObjectFactory._process_time_range`
takes the range from the query's `TEMPORAL_RANGE` filter, so
`from_dttm`/`to_dttm` already carry that filter's bounds before
`_apply_granularity` runs. Once `granularity` is set, `models/helpers.py`
builds the time filter on the granularity column from those same bounds. So the
filter removed here is replaced, not lost. This is the same "replace the
default temporal filter" behaviour that queries with an explicit granularity
already go through.
To pin it, b16ee7f adds
`test_apply_granularity_legacy_query_context_keeps_temporal_filter_bounds`. It
builds the query object with the real `QueryObjectFactory` (no `time_range`, a
`TEMPORAL_RANGE` filter of `2024-01-01 : 2024-02-01`), runs
`_apply_granularity` with a legacy `granularity_sqla`, and asserts that the
filter is removed while `from_dttm`/`to_dttm` keep those bounds and
`granularity` resolves to `ds`.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
