sebastianvillarroel commented on issue #37427: URL: https://github.com/apache/superset/issues/37427#issuecomment-5009545016
> As already stated, SIP #39492 (DB-based versioning, landing in 7.0) supersedes this, it never went to DISCUSS, and export-API/CLI git workflows cover the remaining use case. Closing as superseded, but thank you! This is a solid proposal and a long overdue capability for Superset. The SQLAlchemy-Continuum approach for scalar fields plus JSON snapshots for child collections is a pragmatic architecture given the constraints you've documented. Open Question 3 caught my attention: *"Should dependent charts be notified or validated? What is the user experience when a restored dataset column no longer matches a chart's query?"* This is the harder problem downstream of versioning — knowing a dataset changed is useful, but understanding what broke as a result requires traversing the full dependency graph across datasets, charts, and dashboards. Git history alone doesn't surface that, and neither does database-level version capture. I've been working on this specific problem with [Puxti](https://getpuxti.com) — a tool that detects semantic changes in data definitions and propagates them downstream as reviewable PRs. The version endpoints you're adding (`GET /versions/`, `POST /restore`) look like useful primitives to hook into. I will be having a look and maybe could share my findings? -- 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]
