GitHub user eschutho edited a discussion: [Feature] Support dashboard-context
SQL compilation via filters_dashboard_id on /api/v1/chart/{id}/data
[Feature] Support dashboard-context SQL compilation via filters_dashboard_id on
/api/v1/chart/{id}/data
Summary
Enhance the existing GET /api/v1/chart/{id}/data endpoint to support an
optional filters_dashboard_id parameter that returns the chart’s compiled SQL
as rendered within a specific dashboard context, including applicable dashboard
default filters.
This enables programmatic SQL extraction for validation workflows (e.g.,
warehouse migrations, regression testing, governance).
⸻
Problem
Today:
• GET /api/v1/chart/{id}/data returns a query but does not allow
specifying dashboard context.
• POST /api/v1/chart/data requires reconstructing form_data and
manually injecting filter values.
There is no supported way to:
• Pass a chart_id
• Pass a dashboard_id
• Automatically apply dashboard default filters
• Retrieve the compiled SQL exactly as rendered in a dashboard
This makes automated validation workflows brittle and error-prone.
⸻
Proposed Solution
Extend:
GET /api/v1/chart/{id}/data
To accept an optional parameter:
filters_dashboard_id=<dashboard_id>
Example:
GET /api/v1/chart/123/data/?filters_dashboard_id=456
⸻
Expected Behavior
When filters_dashboard_id is provided:
1. Validate that the chart belongs to the specified dashboard.
2. Identify dashboard filters scoped to the chart.
3. Apply their default values.
4. Construct an effective copy of the chart’s form_data (MUST NOT
mutate stored config).
5. Build a QueryContext from the effective form_data.
6. Generate SQL using the existing datasource query-building
pipeline.
7. Return the response using the existing /chart/{id}/data
response structure.
If filters_dashboard_id is not provided, behavior remains unchanged.
⸻
SQL Parity Requirement
The endpoint MUST reuse the existing dashboard filter application and query
generation pipeline used during dashboard rendering.
It MUST NOT reimplement or duplicate filter-merging logic.
The compiled SQL MUST match the SQL generated when rendering the same chart
inside the dashboard with default filters applied.
⸻
Compile-Only Mode
The endpoint MUST support:
result_type=query
In this mode:
• SQL is compiled but not executed.
• The existing response structure is preserved.
• Each entry in result[] contains the compiled query.
Example:
GET /api/v1/chart/123/data/?result_type=query
⸻
Response Format
The response MUST remain identical to the existing /api/v1/chart/{id}/data
response structure (including support for multiple queries in the result array)
except that it should not query the db for the data or return data.
No breaking changes to the API contract.
⸻
Access Control
• Enforce datasource-level permissions.
• If Dashboard RBAC is enabled, enforce dashboard access
permissions.
• Regardless of RBAC configuration, validate that the chart
belongs to the specified dashboard.
⸻
Out of Scope (V1)
• Batch extraction for multiple charts
• SQL diff tooling
• Interactive filter state overrides
• Cross-dashboard comparisons
⸻
Additional Context
This feature is intended to support:
• Warehouse migration validation
• SQL regression testing
• Governance and audit workflows
• API-first automation use cases
GitHub link: https://github.com/apache/superset/discussions/38133
----
This is an automatically sent email for [email protected].
To unsubscribe, please send an email to:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
