sadpandajoe commented on code in PR #44431:
URL: https://github.com/apache/superset/pull/44431#discussion_r4141325002
##########
superset-frontend/src/components/Datasource/components/DatasourceEditor/components/PartitionFilterMapping/utils.ts:
##########
@@ -34,6 +35,36 @@ import type {
*/
const JINJA_PATTERN = /\{\{|\{%|\{#/;
+/**
+ * Whether the dataset editor should offer partition filter mapping at all.
+ *
+ * The single source of truth for the gate, so every place that shows partition
+ * mapping UI stays in lockstep: it needs the feature flag on, a datasource to
+ * read, and an engine that advertises support
(`supports_partition_filter_mapping`,
+ * true only for partition-directory engines like Hive/Impala/Spark). This
lived
+ * inline at one call site and was missed at another, which showed the section
on
+ * engines that do not support it -- hence one predicate both sites share.
+ */
+export function partitionFilterMappingEnabled(
+ datasource: PartitionMappingDatasource | undefined,
+): boolean {
+ return (
+ isFeatureEnabled(FeatureFlag.PartitionFilterMapping) &&
+ Boolean(datasource) &&
+ Boolean(datasource?.supports_partition_filter_mapping)
Review Comment:
After the database is changed in the editor, this value still comes from the
dataset that was initially loaded. Switching Hive to Postgres leaves the
partition-mapping controls enabled (and the Hive default intact), while the
opposite switch hides them. Could the database-change flow refresh or derive
the capability for the newly selected database?
--
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]
