sadpandajoe commented on code in PR #42752:
URL: https://github.com/apache/superset/pull/42752#discussion_r3718078682


##########
superset/models/helpers.py:
##########
@@ -4162,6 +4162,17 @@ def get_sqla_query(  # pylint: 
disable=too-many-arguments,too-many-locals,too-ma
                         else:
                             cond = is_null_cond
                     else:
+                        # Normalize mixed int/float values before binding, 
since
+                        # SQLAlchemy may infer the bind parameter type from the
+                        # first element and silently truncate other values
+                        # (see #33206)
+                        if target_generic_type == 
utils.GenericDataType.NUMERIC and any(

Review Comment:
   This normalization only runs in the no-NULL branch, so `IN [33, 29.02, 
NULL]` still compiles the fractional value as `29` and omits matching rows. 
Could we hoist the normalization before `eq_without_none` is derived and cover 
the NULL-bearing list?



##########
superset/models/helpers.py:
##########
@@ -4096,6 +4096,17 @@ def get_sqla_query(  # pylint: 
disable=too-many-arguments,too-many-locals,too-ma
                         else:
                             cond = is_null_cond
                     else:
+                        # Normalize mixed int/float values before binding, 
since
+                        # SQLAlchemy may infer the bind parameter type from the
+                        # first element and silently truncate other values
+                        # (see #33206)
+                        if target_generic_type == 
utils.GenericDataType.NUMERIC and any(
+                            isinstance(v, float) for v in eq
+                        ):
+                            eq = [
+                                float(v) if isinstance(v, (int, float)) else v
+                                for v in eq
+                            ]

Review Comment:
   Agreed—mixing `9007199254740993` with a fractional value changes the 
requested integer to `9007199254740992.0`, so exact NUMERIC filters can match 
the wrong row. Could we avoid coercing the original integers to binary float?



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