angrymango commented on issue #43552:
URL: https://github.com/apache/superset/issues/43552#issuecomment-5423940461
**Retracting this — it was two problems on my side, and neither is a
Superset bug. Closing.**
I re-tested after fixing our semantic-layer adapter, and the dashboard now
renders correctly: both chart tiles draw, and the native filters populate their
member lists from the semantic view.
What was actually happening:
1. **The blank tiles** were our adapter returning result columns named after
the underlying model column (`Color`) rather than the dimension id Superset
asked with (`ColorGroups[Color]`). The echarts plugins post-process with a
`pivot` keyed by that id, so the lookup missed and the data request failed.
Fixed in our implementation; the tile requests now carry `datasource: {"id": 1,
"type": "semantic_view"}` and return 200.
2. **The `datasource_type: table` requests** were the *native filters*, not
the charts, and they were correct behaviour: `nativeFilters/utils.ts` builds
the member-list request as `${datasetId}__${datasourceType ||
DatasourceType.Table}`, and `NativeFilterTarget.datasourceType` is exactly the
field that says otherwise. Our tooling wrote targets with `datasetId` and no
`datasourceType`, so the fallback applied. Adding it makes the filters resolve
against the semantic view immediately.
My apologies for the noise — I filed this from the state before (1), which
made the client's `table` fallback look like the cause of the whole dashboard
being dark rather than a consequence of a target we had written incompletely.
One residual observation, offered without a bug claim since nothing seems to
depend on it: `GET /api/v1/dashboard/<id>/datasets` returns `[]` for a
dashboard whose charts are all semantic-view backed, because
`Dashboard.datasources` is derived from `Slice.datasource`, which is the
`SqlaTable` relationship. The dashboard renders regardless. If that payload is
meant to enumerate every datasource a dashboard reads, it currently
under-reports for semantic views; if it is SQLA-specific by design, no action
needed.
The other note in the original report stands on its own if it is of
interest: there is no endpoint that lists semantic views with their ids (`GET
/api/v1/semantic_view/` is 405), so automation that creates charts has to
discover the integer id by probing `/<pk>/structure`. Happy to open that as a
separate feature request if it would be useful.
--
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]
