mikebridge opened a new pull request, #44270:
URL: https://github.com/apache/superset/pull/44270
### SUMMARY
`get_table` had no way to choose a time grain on a semantic view, so
"revenue by month" was not expressible through the tool:
* `dimensions: ["metric_time__month"]` (the grain-variant id Explore's
time-grain control uses) → `ValidationError: Unknown dimension:
'metric_time__month'. Did you mean: metric_time?`
* `dimensions: ["metric_time"]` → succeeds, but silently returns whichever
variant the layer picks (DAY) as `metric_time__day`, typed `data_type:
"string"` with values like `"2024-09-01T00:00:00Z"`.
The plumbing already existed on both sides and was simply never connected:
`build_query_dict` (`superset/common/tabular_query.py`) emits a `BASE_AXIS`
column plus `extras["time_grain_sqla"]` when given `time_grain`/`grain_column`,
and the semantic-layer mapper resolves that to the matching per-grain dimension
variant.
* **`GetTableRequest.time_grain`** — an ISO-8601 duration (`P1M`) or a grain
name (`month`, case-insensitive), normalized from the `Grains` registry rather
than a second hardcoded table.
* **Validated against the view's own grains**
(`SemanticView.get_time_grains()`); an unsupported value is refused with the
view's queryable grains listed. It applies to `time_column`, otherwise to the
single selected temporal dimension; selecting several temporal dimensions
without `time_column` is an explicit ambiguity error rather than a silent pick.
Built-in datasets reject the parameter instead of ignoring it.
* **Grain-alias hint** — a dimension shaped `<temporal dimension>__<grain
name>` adds a hint naming the base dimension and the `time_grain` value to use,
alongside the existing "Did you mean".
* **Temporal typing** — `format_data_columns` takes an optional explicit set
of temporal column names (omitted ⇒ existing inference, so every other caller
is byte-identical); `get_table` passes its datasource's temporal columns and
matches the `<dimension>__<grain>` ids semantic views return. Temporal columns
are typed `datetime` instead of `string`.
### BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF
Live `superset mcp run` against the Jaffle Shop semantic view:
```
{"view_id": 1, "metrics": ["revenue"], "dimensions": ["metric_time"],
"time_grain": "P1M"}
before: (no such parameter)
after: columns [("metric_time", "datetime"), ("revenue", "numeric")]
rows 2024-09-01T00:00:00Z 15218.0 | 2024-10-01T00:00:00Z
19422.0 | 2024-11-01T00:00:00Z 24135.0
"time_grain": "month" → identical result
"time_grain": "PT1S" → Unsupported time_grain 'PT1S' on view 'Jaffle
Shop'.
Queryable grains: P1D (Day), P1M (Month), P1W
(Week), P1Y (Year), P3M (Quarter).
dimensions ["metric_time__month"] → …Did you mean: metric_time?; For
'metric_time__month', request
dimension 'metric_time' and pass time_grain='P1M'
instead.
no time_grain (unchanged path) → column metric_time__day, now typed datetime
rather than string
```
### TESTING INSTRUCTIONS
```
pytest tests/unit_tests/mcp_service/semantic_layer/
tests/unit_tests/mcp_service/utils/
```
Tests cover the grain reaching the query dict (`extras["time_grain_sqla"]`
and the BASE_AXIS `timeGrain`) for both the duration and the name form, the
unsupported-grain error listing the view's grains, the alias hint, the
ambiguity error, the built-in rejection, and `datetime` typing. The typing and
grain-threading tests were both verified red-first (`assert 'string' ==
'datetime'`; `KeyError: 'extras'`).
### ADDITIONAL INFORMATION
- [x] Has associated issue: sc-120962
- [ ] Required feature flags:
- [ ] Changes UI
- [ ] Includes DB Migration (follow approval process in
[SIP-59](https://github.com/apache/superset/issues/13351))
- [ ] Migration is atomic, supports rollback & is backwards-compatible
- [ ] Confirm DB migration upgrade and downgrade tested
- [ ] Runtime estimates and downtime expectations provided
- [ ] Introduces new feature or API
- [ ] Removes existing feature or API
🤖 Generated with [Claude Code](https://claude.com/claude-code)
https://claude.ai/code/session_01267VBWbvWTNZUg9GvXKgkC
--
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]
