tomerkl65 commented on issue #43331: URL: https://github.com/apache/superset/issues/43331#issuecomment-5552015432
Thanks — I largely agree with the sequencing, and I think the case for shipping now is actually a bit stronger than "no blocker found," because the seam you're describing already exists in the implementation in all but name. Today the interaction layer never consumes the raw `drilldown_hierarchy: string[]` directly. There's a single resolution step that takes the configured chart-local source, normalizes it against the chart's primary dimension (`x_axis` / first `groupby`), and produces an **ordered list of drillable dimensions**. Everything downstream — the click progression, query/filter updates, cross-filter emission, and breadcrumb — consumes only that resolved ordered sequence. So the `configured source → resolve once → ordered drillable dimensions → existing drill interaction` boundary is effectively how it's already structured; it's just implicit. That makes your "narrow boundary if it stays cheap" condition easy to satisfy here. Making it explicit is a small concentration of normalization that already exists (naming the resolution step and giving it a documented contract), not a new persistence/API/provider model and not broad refactoring. A later dataset-owned or semantic-layer source could plug into that one resolution step without the interaction layer knowing where the hierarchy came from. On the dependency question: I couldn't find a concrete dataset/semantic-layer hierarchy contract, saved shape, or in-flight implementation that this would need to stay compatible with — which matches your own read. If someone closer to the semantic-layer work knows of an in-progress interface that's incompatible with the current saved/query shape, that's the one thing worth confirming before we commit to the boundary. One refinement on scope: I'd keep the explicit boundary on the **seam** (the `source → resolve` function), not on the **output type**. Your caveat that not every future hierarchy reduces to `string[]` (parent-child, provider-native) is the real risk. So I'd define the contract as "resolve to an ordered sequence of drillable levels" with the level kept as a minimal, slightly opaque type rather than a bare `string`. That way a future parent-child or provider-native source changes the resolution step without forcing a rewrite of the interaction layer, and we avoid treating `string[]` as the permanent contract. Net: ship now, make the source/resolve seam explicit (it's cheap here), but phrase the contract around an ordered sequence of levels rather than `string[]`. -- 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]
