debabsah commented on issue #39827: URL: https://github.com/apache/superset/issues/39827#issuecomment-4952980163
Strong +1, with a data point from outside the repo: the duplication is not just in the MCP service. I build an open-source tool that creates dashboards programmatically, and to produce valid charts without a browser it mirrors the buildQuery behavior in typed Python. On @aminghadersohi's second point, we run a small working instance of that versioning contract today: the options each viz plugin's controlPanel declares, extracted from source per release (currently 4.1.4, 5.0.0, and 6.1.0), plus a CI check that fails when an emitted option is no longer declared by the target release. The drift it catches is real and silent; for example, the big-number subheader controls became subtitle controls in 6.1, and nothing server-side declares that change. Extraction and checker: https://github.com/debabsah/chartwright/blob/main/tools/params_drift.py Cited behaviors: https://github.com/debabsah/chartwright/blob/main/docs/CONTRACTS.md Two observations from living on both sides of the persistence question: 1. We hit both paths. Creation persists a generated query_context with each chart; post-create verification builds one in memory and feeds it straight to the chart-data API to prove each chart returns data. A persist-only sidecar covers the first and leaves the second duplicated in every client, so +1 on the ephemeral/direct response mode. 2. The versioning contract is most useful published per release and queryable, not only pinned inside the sidecar artifact: clients that target several Superset versions at once (environment promotion, mixed fleets) need to know what each release declares, not just run a matched sidecar. Happy to contribute the per-version extraction data or test cases. -- 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]
