leaves12138 commented on code in PR #1088:
URL: https://github.com/apache/paimon-rust/pull/1088#discussion_r4236394606


##########
bindings/python/src/predicate.rs:
##########
@@ -518,20 +529,8 @@ fn leaf_to_predicate(
             ensure_no_literals(method, literals_obj)?;
             pb.is_not_null(&field)
         }
-        "in" => {
-            let ds = to_datums(literals_obj)?;
-            if ds.is_empty() {
-                return Err(PyValueError::new_err("'in' requires at least 1 
literal"));
-            }
-            pb.is_in(&field, ds)
-        }
-        "notIn" => {
-            let ds = to_datums(literals_obj)?;
-            if ds.is_empty() {
-                return Err(PyValueError::new_err("'notIn' requires at least 1 
literal"));
-            }
-            pb.is_not_in(&field, ds)
-        }
+        "in" => pb.is_in_with_nulls(&field, to_nullable_datums(literals_obj)?),

Review Comment:
   [P2] Update the binding regression for accepted empty IN lists
   
   This correctly allows an empty IN list, but 
`bindings/python/tests/test_read.py:1055` still wraps `with_filter({"method": 
"in", "field": "id", "literals": []})` in `pytest.raises(ValueError)`. With the 
extension rebuilt from this head, `python -m pytest 
tests/test_read.py::test_filter_wrong_literal_count_raises` deterministically 
fails with `DID NOT RAISE ValueError`; this is also the only failure in the 
selected binding suites (298 passed, 1 failed). The normal Python integration 
target runs this test via `make install && make test`, so the stale assertion 
blocks that target.
   
   Please update the old test while retaining the invalid-arity check for 
`equal`, and add positive binding read assertions for empty IN and empty NOT IN 
on nullable data. Keep the new production behavior: Java IN with an empty set 
matches no rows, and NOT IN with an empty set matches only non-NULL rows. 
Restoring the previous empty-list rejection would break the intended Java 
parity.



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

Reply via email to