john-bodley opened a new pull request, #24418: URL: https://github.com/apache/superset/pull/24418
<!--- Please write the PR title following the conventions at https://www.conventionalcommits.org/en/v1.0.0/ Example: fix(dashboard): load charts correctly --> ### SUMMARY This PR provides a fix for https://github.com/apache/superset/pull/14710 in addition to being an alternative formulation for https://github.com/apache/superset/pull/24413. Additionally it provides `LIKE` and `ILIKE` operator support for SIMPLE ad-hoc filters irrespective of the column type, i.e., now all operators are valid. This change came about give how https://github.com/apache/superset/pull/14710 implemented dynamic (backend) filtering of numerical values for native filters. Hypothetically lets assume there was an `id` column which comprised of the set of integers from 0 to 100,000 and a user searched for `100`, then: 1. A backend query was sent with a SIMPLE filter of the form `{col: 'my_col', op: '>=', val: 100}`. 2. The result set (limited to 1,000) would contain the values 100, 101, 102, ..., 1,097, 1,098, 1,099 3. The frontend select filter would filter out any result not match the `100` substring resulting in 100, 1,001, 1,002, 1,003, 1,004, 1,005, 1,006, 1,0007, 1,008, 1,009. 4. Numerous valid matches like 1,100, 2,100, 10,000, etc. aren't shown as they're not part of the corpus of 1,000 results fetched from the backend. The right way to see if a number is contained within another number is to treat the numbers as a string and provide a filter of the form `{col: 'my_col', op: 'ILIKE', val: '%100%'}`. This also remedies the BIGINT issue where in https://github.com/apache/superset/pull/24413 the numerical values were treated as a string. The ad-hoc filters include the `ILIKE` and `LIKE` operator which work exclusively with `STRING` types. This PR simply provides "support" for using both these operators by casting the column (if necessary) to a `STRING`, i.e., it means that the `ILIKE` and `LIKE` operator work for all SIMPLE filters irrespective of the column type, which can then be leveraged by the native filter search functionality. ### BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF <!--- Skip this if not applicable --> ### TESTING INSTRUCTIONS <!--- Required! What steps can be taken to manually verify the changes? --> ### ADDITIONAL INFORMATION <!--- Check any relevant boxes with "x" --> <!--- HINT: Include "Fixes #nnn" if you are fixing an existing issue --> - [ ] Has associated issue: - [ ] Required feature flags: - [ ] 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 -- 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: notifications-unsubscr...@superset.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: notifications-unsubscr...@superset.apache.org For additional commands, e-mail: notifications-h...@superset.apache.org
