[SIP-216] Add extensible extra metadata field to charts (slices)

[bsovran]

[SIP] Proposal for adding an extensible extra metadata field to charts (slices)

Motivation

Superset datasets already support flexible metadata via the extra field, but charts (slices) do not have an equivalent extensible storage field.

Teams building chart-level guidance and automation (for example, human-authored interpretation notes and machine-readable chart semantics) need a structured place to store metadata that does not fit into description, certification_details, or chart form data.

Using description for this purpose is limiting because it is a user-facing text field rendered in UI contexts where structured JSON does not belong. Adding a flexible chart-level metadata field would provide a clear, first-class place for this type of information.

Proposed Change

Add a new nullable extra column to the slices table and corresponding Slice model field.

• Column name: extra
• Storage: JSON serialized as text (matching existing Superset patterns)
• SQLAlchemy type: MediumText (superset.utils.core.MediumText)
• Nullability: nullable, no server default

MediumText is preferred over Text because chart metadata payloads can grow beyond small note-sized content, and existing large JSON-like chart fields (params, query_context) already use MediumText.

Also include extra in chart import/export fields so metadata round-trips cleanly.

New or Changed Public Interfaces

This SIP proposes the DB/model foundation first:

• New model attribute on Slice: extra
• New DB column: slices.extra

A follow-up change can expose this through chart REST schemas (ChartPostSchema, ChartPutSchema, GET response schema), but this proposal focuses on establishing the persisted storage contract.

New dependencies

None.

Migration Plan and Compatibility

• Add Alembic migration to create nullable extra column on slices.
• Downgrade removes the column.
• Fully backward compatible:
  • Existing charts unaffected (NULL default state).
  • Existing API behavior unchanged until schema exposure is added.

Rejected Alternatives

1. Reuse description

   • Rejected because it is a user-facing prose field and not appropriate for structured metadata.

2. Add a separate chart annotation table

   • Rejected for now due to added complexity and join overhead for a use case that can be modeled as chart-scoped extensible metadata.

3. Store metadata only in frontend/local state

   • Rejected because metadata should be durable, versionable, and shared across users and automation workflows.

[BenikamSrikar]

Hi @bsovran, this looks like a clean, well-scoped proposal — thanks for writing it up.
I'd like to take a shot at implementing this if it's cleared to proceed. A bit of context: I'm a CS student with hands-on experience building backend systems (Node.js/Express, REST APIs) and solid coursework in DBMS, so I'm comfortable with the data modeling and migration side of this (nullable column, MediumText, Alembic upgrade/downgrade). I haven't contributed to Superset before, so I'll be ramping up on the codebase conventions as I go, but I'm happy to put in the time to get it right and iterate on review feedback.
Before I start: is this SIP considered approved to implement, or does it still need broader discussion/a vote given it touches the data model? Want to make sure I'm not jumping ahead of the process. If it's good to go, I'll start with the Slice model field + migration + import/export field addition as scoped, and open a draft PR early so you can sanity-check direction before I go further.

[bsovran]

Opened a PR implementing the model + migration foundation for this proposal: #41200

It adds a nullable extra (MediumText) column to slices, mirroring the existing dataset extra pattern. API/schema and UI exposure can follow in subsequent PRs.

[BenikamSrikar]

Thanks for the quick turnaround on the implementation @bsovran! I see the API/schema exposure is planned as a follow-up — happy to take that on if you'd like a hand. Let me know if a separate issue will be opened for it or if I should watch #41200 for next steps.

[gabotorresruiz]

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.

[bsovran]

@gabotorresruiz agree with the long term goals here not being great to push into the extra column.
The motivation for me is getting out flexible storage quickly for features Robinhood wants to leverage, but I'd be happy to contribute to those discussions and provide a case study on how this goes for us.
Long term we might sync up with whatever gets merged into master, and granted extra is agnostic I thought it would be clean to contribute to open source as others might also benefit from leverage this for their own asks.