eschutho opened a new pull request, #44431:
URL: https://github.com/apache/superset/pull/44431
### SUMMARY
The partition filter mapping feature (the 6-PR stack this builds on) lets a
chart author's filter on one column be mirrored onto a table's physical
partition column so Hive/Impala-family engines can prune partitions. PR
#43891 made the *transform pre-fill* engine-aware by adding
`BaseEngineSpec.partition_value_transform_default`, set to
`unix_timestamp(:value)` on `HiveEngineSpec`/`ImpalaEngineSpec` (Spark
inheriting from Hive) and deliberately left `None` on Presto.
That only decides **which default transform to suggest**, not **whether the
feature should be offered at all**. There was no per-engine gate:
- The editor gate in `DatasourceEditor.tsx` was
`isFeatureEnabled(FeatureFlag.PartitionFilterMapping) &&
Boolean(datasource)`
-- the "Partition column" dropdown appeared on **every** database whenever
the flag was on.
- `validate_partition_mapping` receives `engine=database.backend` but only
uses it to check the transform text parses for that dialect, never to
reject the feature on engines where partition-directory pruning does not
structurally apply.
So a Postgres, Snowflake, BigQuery or Redshift dataset showed the exact same
"Partition column" UI as an Impala one. Mirroring a filter onto a physical
partition column only prunes work on engines whose tables are laid out as
partition directories (Hive-family). On Postgres the concept does not exist;
Snowflake micro-partitions are automatic and invisible; BigQuery and Redshift
use different mechanisms entirely. There the dropdown is clutter that maps to
nothing.
**The fix** adds a capability flag that travels alongside the existing
transform default, on exactly the same engines:
- `BaseEngineSpec.supports_partition_filter_mapping: bool = False`, set
`True` on `HiveEngineSpec` and `ImpalaEngineSpec`; `SparkEngineSpec`
inherits it from Hive. Presto/Trino and everything else stay `False`,
matching the decision that left `partition_value_transform_default` off
Presto.
- Threaded to the client the identical way the transform default is: a
read-only `SqlaTable.supports_partition_filter_mapping` property sourced
from the engine spec, exposed via `DatasetRestApi.show_columns`, and added
to the frontend datasource types.
- The editor's `partitionMappingEnabled` gate now also requires the flag, so
the partition mapping UI only appears on an engine that advertises support.
This PR is scoped to the capability gate only; it does not change the mapping
logic, the transform default, or the set of in-scope engines.
While in this area, one stale UI string is also corrected: the "Partition
column" field's helper text claimed selecting a column "hides it from
Explore's
dimension and filter pickers by default." Designating a partition column has
no
such effect (it does not touch the column's `filterable`/`groupby` flags; the
row only gets muted styling via the `partition-column-row` CSS class), so
that
sentence is removed.
The first commit (`style(explore): apply oxfmt to the datasource editor`) is
a
no-op reformat: the `<CollectionTable>` block in `DatasourceEditor.tsx` was
indented one level short of its wrapper and `oxfmt` flags it, so any change
touching the file has to reformat it. It is split out so the capability-gate
diff stays reviewable.
### BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF
N/A -- the observable change is the absence of the "Partition column" section
in the dataset editor's Columns tab on engines that do not support partition
directories (e.g. Postgres), while it continues to appear on
Hive/Impala/Spark.
### TESTING INSTRUCTIONS
1. Enable the `PARTITION_FILTER_MAPPING` feature flag.
2. Open the dataset editor for a Hive, Impala or Spark dataset -> the
partition filter mapping controls appear.
3. Open the dataset editor for a Postgres (or Snowflake/BigQuery/Redshift)
dataset -> the partition filter mapping controls are no longer offered.
Automated:
- `pytest tests/unit_tests/db_engine_specs/test_hive.py
tests/unit_tests/db_engine_specs/test_impala.py
tests/unit_tests/datasets/partition_mapping_serialization_test.py`
- `npm run test -- src/components/Datasource/components/DatasourceEditor`
### ADDITIONAL INFORMATION
- [ ] Has associated issue:
- [x] Required feature flags: `PARTITION_FILTER_MAPPING`
- [x] Changes UI
- [ ] Includes DB Migration (follow approval process in
[SIP-59](https://github.com/apache/superset/issues/13351))
- [ ] Migration is atomic, supports rollback & is backwards-compatible
- [ ] Confirm DB migration upgrade and downgrade tested
- [ ] Runtime estimates and downtime expectations provided
- [ ] Introduces new feature or API
- [ ] Removes existing feature or API
---
**Follow-up fixes in this PR (same area):**
- Removed the stale helper text under the "Partition column" field that
claimed
selecting a column hides it from Explore's dimension and filter pickers.
- Removed the behavior behind it: designating a partition column previously
forced the column's `filterable`/`groupby` flags off
(`applyPartitionColumnDefaults`). Hiding the partition column is a
per-column
decision the owner makes, not a side effect of the mapping, so that flag
mutation and its call site are removed; the muted row styling stays.
- The "Value transform" field now defaults to the bare `:value` identity
transform (instead of an empty field) for the cases that previously
pre-filled
nothing -- non-temporal columns and temporal columns on engines with no
engine-specific default (Postgres/Presto). The engine default still wins
where
it applies. Because `:value` provably preserves ordering, a fresh pre-fill
of
it auto-declares monotonicity, and editing the transform away from exactly
`:value` clears that auto-declaration so nothing stale lingers.
--
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]
