varadendrasimha511 opened a new pull request, #42752:
URL: https://github.com/apache/superset/pull/42752

   ### SUMMARY
   Fixes #33206.
   
   When a numeric filter combines integer and decimal values (e.g. `IN (33, 
29.02)`), SQLAlchemy may infer the bind parameter type from the *first* value 
in the list. If that first value is an `int`, subsequent `float` values in the 
same `IN` clause can be silently truncated during query compilation — dropping 
their decimal precision entirely and causing matching rows to disappear from 
results without any error.
   
   This was reproduced and root-caused end-to-end:
   - Confirmed the frontend sends the correct, full-precision value (via 
browser DevTools network payload)
   - Confirmed the value arrives correct and untouched through 
`cast_to_num`/`handle_single_value`
   - Confirmed the column's SQLAlchemy type is correctly `Float`
   - Confirmed via debug logging that `eq` (the filter value list) is still 
fully correct immediately before `sqla_col.in_(eq)` is called
   - Isolated the exact trigger: only reproduces when an `int` and `float` are 
combined in the same `IN` list — decimals alone, or ints alone, both work 
correctly
   
   The fix normalizes mixed int/float values to `float` right before binding, 
only when the target column is numeric and the list actually contains a mix — 
so purely-integer filters (e.g. ID lookups) are unaffected, addressing the 
earlier concern in #33230 about integer precision loss for large IDs.
   
   ### BEFORE/AFTER
   **Before:** Filtering `global_sales IN (33, 29.02)` on a table with both 
integer and decimal sales values silently drops the row matching `29.02`, 
returning only the row matching `33`.
   
   **After:** Both rows are correctly returned.
   
   ### TESTING INSTRUCTIONS
   1. Create a Table chart on any dataset with a float column containing both 
whole-number and decimal values (e.g. `video_game_sales.global_sales`)
   2. Add an "is in" filter with one integer-like value and one decimal value 
(e.g. `33` and `29.02`)
   3. Before this fix: only the integer-matching row appears
   4. After this fix: both rows appear correctly
   
   Added `test_get_sqla_query_in_filter_preserves_float_precision` in 
`tests/unit_tests/models/helpers_test.py`, which compiles the generated SQL and 
asserts the float value's precision is preserved in the `IN` clause.
   
   ### ADDITIONAL INFORMATION
   - [x] Has associated issue: #33206
   - [x] Required feature flags: N/A
   - [x] Changes UI
   - [ ] Includes DB Migration (no)
   - [x] Confirm DB Migration upgrade and downgrade tested (N/A, no migration)
   - [x] Introduces new feature or API (no, bug fix only)
   - [ ] Removes existing feature (no)


-- 
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]

Reply via email to