CIF84 commented on issue #43331: URL: https://github.com/apache/superset/issues/43331#issuecomment-5519099440
I think the current public evidence favors shipping rather than waiting, with one narrow boundary if it stays cheap. The reason is mostly sequencing: I couldn't find a concrete dataset/semantic-layer hierarchy contract, implementation, milestone, or reliable landing horizon that the chart-local version needs to wait for. At the same time, the discussion already points toward reusable dataset-owned hierarchies and possible semantic-layer hydration, so treating the inline `drilldown_hierarchy: string[]` as the permanent interaction contract seems unnecessarily binding. A minimal S2 could be: `configured hierarchy source → resolve once → ordered drillable dimensions → existing drill interaction` For the current version, the configured source remains the chart-local list. The click progression, query/filter updates, cross-filter emission, and breadcrumb behavior would consume only the resolved ordered sequence. A later compatible dataset or semantic-layer source could plug into the resolution step without requiring the interaction to understand where the hierarchy came from. This is intentionally not a proposal for the future hierarchy schema. It does not choose identifiers, persistence, sync, precedence, rename behavior, provider APIs, or migration mechanics. It also does not assume every future hierarchy reduces to `string[]`; parent-child or provider-native hierarchy semantics may need a different interaction contract. My recommendation would therefore be: ship now with this source/interaction boundary if making it explicit is a small concentration of the normalization already present. If it requires broad refactoring, a new persistence/API/provider model, or other speculative architecture, ship the current chart-local representation unchanged and revisit migration when a real contract exists. The strongest reason to wait would be concrete project knowledge that a near-term hierarchy interface is already being implemented and is incompatible with the current saved or query shape. Is there such a dependency or implementation constraint, or another reason this sequencing would be wrong? -- 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]
