hughhhh opened a new pull request, #45557:
URL: https://github.com/apache/superset/pull/45557
### SUMMARY
Stacked on #43870. Addresses the review note there that temporal probe
results pass validation but produce invalid SQL on Trino/Presto.
**The bug.** When a transform answers with a DATE or TIMESTAMP, the probe
returns a Python `date`/`datetime`. `probed_value_type_error` admits any
`date`/`datetime` for a temporal partition column, and `literal_round_trips`
skips non-strings. The value then reaches `handle_comparison_filter` as a bind
compiled with `literal_binds`, and the driver's literal processor writes it as
plain quoted text on every dialect. On Trino this gives `part >= '2026-01-01'
OR part IS NULL`. The same path never calls `convert_dttm`, which is what the
chart's own time filter uses.
Reproduced on Trino 484:
- `p >= '2026-01-01'` fails with `Cannot apply operator: date <=
varchar(10)`.
- `ts >= '2026-01-01 00:00:00'` fails with `Cannot apply operator:
timestamp(6) <= varchar(19)`.
- `p IN ('2026-01-01')` fails with `Cannot find common type between date and
varchar(10)`.
- `DATE '…'` and `TIMESTAMP '…'` literals work.
The mirror is ANDed onto the chart query, so the whole chart failed.
Meanwhile the preview endpoint returned `valid: true` with that predicate.
Presto and Athena behave the same way. Hive, Impala, Snowflake, Postgres and
MySQL coerce the text implicitly, and BigQuery's dialect already writes typed
literals.
**The fix.** A probed `date`/`datetime` is now written with the engine
spec's `convert_dttm`, the same function `dttm_sql_literal` uses for every
other temporal bound:
- Trino/Presto: `DATE '2026-01-01'`
- Hive/BigQuery: `CAST('2026-01-01' AS DATE)`
The mirror is declined, which costs only the pruning, in two cases:
- The spec has no literal for the column's type. This matches how
`_reads_as_temporal` treats engines Superset hasn't confirmed.
- The literal would drop part of the value: SQLite floors to the second,
Presto to the millisecond. A floored upper bound is narrower than the filter
and would drop rows. This is detected by rendering the value and the value
minus 1µs and comparing the text. A DATE column is exempt, because flooring to
the day is its own resolution.
`probed_value_type_error` applies the same check, so preview returns `valid:
false, reason: "type"` with an explanation instead of a predicate.
`_predicates_from_probe` keeps a backstop for column types the gate could not
resolve. IN lists get the same rendering.
### TESTING INSTRUCTIONS
Run the partition-mapping unit suites. Locally (partition mapping, preview,
mirroring, serialization, dataset API and `db_engine_specs`): 2,974 passed. The
one failure, `test_sql_validation_engines_matches_docs_generator`, is
environmental: `docs/` was not mounted in the container. ruff is clean, and
mypy with `--check-untyped-defs` (reproducing the CI hook) is clean on the
touched files.
New tests:
- Dialect-level rendering across Trino, Presto, Hive and BigQuery, for DATE
and TIMESTAMP keys, with `>=`, `==` and IN. Each asserts the engine literal and
that no bare quoted temporal text remains. This includes a `date` answer for a
TIMESTAMP key.
- The exact Trino predicate: `part >= DATE '2026-01-01' OR part IS NULL`.
- Declines: a sub-second answer on SQLite, and a spec without
`convert_dttm`. A whole-second answer on SQLite and a timestamp answer for a
DATE key still mirror.
- Preview: valid with the `TIMESTAMP '…'` literal on Trino, and invalid with
`reason: "type"` for a sub-second answer on SQLite.
The new message is added to `messages.pot` and to every `.po` catalog as an
untranslated entry. Nothing else in the catalogs changes.
### ADDITIONAL INFORMATION
- [ ] Has associated issue:
- [ ] Required feature flags: `PARTITION_FILTER_MAPPING`
- [ ] Changes UI
- [ ] Includes DB Migration
- [ ] Introduces new feature or API
🤖 Generated with [Claude Code](https://claude.com/claude-code)
--
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]
