rusackas opened a new pull request, #42595:
URL: https://github.com/apache/superset/pull/42595
### SUMMARY
This is a **test-only PR** opened as a TDD-style validation of issue #35263.
#35263 (filed 2026, reproduced on 5.0.0) reports that Drill to Detail /
Drill by on charts backed by Jinja-templated (virtual SQL) datasets returns
zero rows, even though the parent chart clearly shows data for the selected
value. dosubot's diagnosis pointed at an architectural gap: drill queries send
filters in the native `{col, op, val}` format used by
`QueryContext`/`query_obj["filter"]`, not the `adhoc_filters` format that
`filter_values()`/`get_filters()` originally only read from the Flask request's
form data — so a Jinja dataset's `filter_values()` call would see nothing
during a drill request.
Investigating on master, that specific gap is **already closed**:
`ExtraCache.get_filters()` in `superset/jinja_context.py` falls back to
`_get_filters_from_query_context()`, which reads `query_obj["filter"]` (the
native format) when the adhoc-filters lookup finds nothing. That fallback
already has thorough isolated unit coverage in
`tests/unit_tests/jinja_context_test.py` (e.g.
`test_filter_values_query_context_filters`), but nothing exercised it through a
real **virtual dataset** end-to-end via `SqlaTable.get_sqla_query` — the exact
code path the reporter's Jinja-templated dataset goes through.
This PR adds that missing end-to-end regression test:
1. **`test_get_sqla_query_virtual_dataset_filter_values_drill_to_detail`** —
builds a virtual `SqlaTable` whose own SQL calls `filter_values('b')` in a
`WHERE` clause (mirroring the reporter's `{% if filter_values(...) %} AND col
IN {{ filter_values(...) | where_in }} {% endif %}` pattern), calls
`get_sqla_query(..., filter=[{"col": "b", "op": "IN", "val": ["Alice"]}])` —
the native format Drill to Detail/Drill by send — and asserts the compiled SQL
contains the drilled-into value.
### How to interpret CI
- **CI green** (expected, confirmed locally) → the native-filter fallback
already covers virtual/Jinja datasets end-to-end; the specific mechanism
reported in #35263 is fixed on master. This PR can be merged as a regression
guard; #35263 can likely be closed once a reporter or maintainer confirms
current behavior on 5.x/master, since the originally diagnosed root cause no
longer reproduces.
- **CI red** → the fallback doesn't actually reach virtual dataset SQL
templating the way isolated `ExtraCache` unit tests suggest; look at
`SqlaTable.get_sqla_query` → `template_kwargs["filter"]` →
`get_template_processor(**template_kwargs)` wiring in
`superset/models/helpers.py`.
### TESTING INSTRUCTIONS
```bash
pytest
tests/unit_tests/models/helpers_test.py::test_get_sqla_query_virtual_dataset_filter_values_drill_to_detail
-v
```
### ADDITIONAL INFORMATION
- [x] Has associated issue: closes #35263
- [ ] Required feature flags
- [ ] Changes UI
- [ ] Includes DB Migration
- [ ] Introduces new feature or API
- [ ] Removes existing 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]
