clintropolis commented on a change in pull request #10084:
URL: https://github.com/apache/druid/pull/10084#discussion_r446486836
##########
File path: core/src/test/java/org/apache/druid/math/expr/ParserTest.java
##########
@@ -172,6 +173,43 @@ public void testMixed()
validateFlatten("min(1, max(3, 4))", "(min [1, (max [3, 4])])", "1");
}
+ @Test
+ public void testBitwiseOps()
+ {
+ validateFlatten("3 & 1", "(& 3 1)", "1");
+ validateFlatten("3 & 1", "(& 3 1)", "1");
+ validateFlatten("2 & 1", "(& 2 1)", "0");
+ validateFlatten("3 | 1", "(| 3 1)", "3");
+ validateFlatten("2 | 1", "(| 2 1)", "3");
+ validateFlatten("(~1) & 7", "(& ~1 7)", "6");
+
+ validateFlatten("'2' & '1'", "(& 2 1)", "0");
+ validateFlatten("'3' | '1'", "(| 3 1)", "3");
+ validateFlatten("(~'1') & 7", "(& ~1 7)", "6");
+
+ validateFlatten("'notanumber' & '1'", "(& notanumber 1)", null);
+ validateFlatten("'3' | 'notanumber'", "(| 3 notanumber)", null);
+ validateFlatten("~'notanumber'", "~notanumber", null);
+ validateFlatten("(~'notanumber') & '7'", "(& ~notanumber 7)", null);
+ validateFlatten("(~'notanumber') | '7'", "(| ~notanumber 7)", null);
Review comment:
Hmm, this actually brings up something worth thinking about actually,
and I'm not exactly certain what the most correct behavior is to have here.
A test (at least here) would use a `null` constant, which
`BinaryEvalOpExprBase` currently is _not_ short circuited to return `null`
unless `NullHandling.sqlCompatible()` is set.
The "default" evaluator in `BinaryEvalOpExprBase` is `evalDoubles` if none
of the other conditions match, and the other evaluators (`evalString` and
`evalLong`) both require left and right expressions to be the same type, which
the `null` constant makes not be true unless the other expression is
`ExprType.STRING`.
This means tests using a `null` constant and a number on the other side end
up in `evalDoubles`, which for these bitwise expressions will
```
throw new IllegalArgumentException("unsupported type " + ExprType.DOUBLE);
```
which seems sort of funny, and not really correct.
I'm not really certain that `evalDouble` being the default makes sense, but
even if it does, i'm not certain what the correct behavior in default mode if a
null constant is involved (there would never be a null number from a column in
default mode).
I think it really comes down to what should be the behavior in default mode
of the `null` constant when used in a number expression. The `'notanumber'`
string case evaluates to null eventually, even in default mode, while `null`
does not, which seems inconsistent.
##########
File path: docs/misc/math-expr.md
##########
@@ -35,13 +35,15 @@ This expression language supports the following operators
(listed in decreasing
|Operators|Description|
|---------|-----------|
-|!, -|Unary NOT and Minus|
+|!, -, ^|Unary NOT, Minus, and bitwise Negate|
Review comment:
oops, thanks :+1:
----------------------------------------------------------------
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.
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
