gabotorresruiz commented on issue #41171: URL: https://github.com/apache/superset/issues/41171#issuecomment-4753435609
Thanks for putting this together @bsovran, the motivation resonates. Charts genuinely lack a first-class metadata field, `description` is the wrong home for structured data, and mirroring the dataset/column/metric `extra` pattern is a sensible, low-risk foundation. +1 on the column. Since the API/schema exposure is already lined up as the next step, a couple of things feel worth settling there early, since that layer becomes the contract automation reads: 1. **Structure inside extra**. Dataset `extra` shows the risk: over time it collected unnamespaced, ad-hoc keys from different producers. Since the goal here is machine-readable semantics, a light namespacing + `version` convention would let features write without colliding and consumers evolve gracefully, rather than exposing `extra` as an opaque pass-through blob. 2. **Altitude**. A lot of "how to read this" (what a metric means, units, which direction is good) is really about the underlying metric or column, where `description/verbose_name/extra` already exist and are authored once and reused. Worth scoping chart `extra` to genuinely chart-specific context so the same meaning isn't re-typed per chart and drifting out of sync. None of this blocks the foundational column, which looks clean. Just want the follow-up to define a contract we can all build on. Happy to help think through the schema convention. -- 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]
