You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on May 10, 2024. It is now read-only.
An operation of the form CHECK x = 10 OR var1 = col1, currently gets compiled down to a series of ortools operations that constructs the full expression without returning early. If x=10 but var1 is null, we still get an NPE when passing an argument to Ops.
The above operation is equivalent to WHERE x != 10 CHECK var1 = col1, which generates an if-expression that only encodes the constraints for rows that pass the x != 10 predicate. Doing so makes this safe for use cases where var1 might be null if x=10 but has a value otherwise.
It's worth considering what the behavior should be in the presence of nulls and whether we can potentially rewrite the IR.
The text was updated successfully, but these errors were encountered:
An operation of the form
CHECK x = 10 OR var1 = col1
, currently gets compiled down to a series of ortools operations that constructs the full expression without returning early. Ifx=10
but var1 is null, we still get an NPE when passing an argument to Ops.The above operation is equivalent to
WHERE x != 10 CHECK var1 = col1
, which generates an if-expression that only encodes the constraints for rows that pass thex != 10
predicate. Doing so makes this safe for use cases where var1 might be null ifx=10
but has a value otherwise.It's worth considering what the behavior should be in the presence of nulls and whether we can potentially rewrite the IR.
The text was updated successfully, but these errors were encountered: