clintropolis commented on a change in pull request #10635:
URL: https://github.com/apache/druid/pull/10635#discussion_r538058342
##########
File path: core/src/main/java/org/apache/druid/math/expr/Function.java
##########
@@ -3275,4 +3276,86 @@ public ExprEval apply(List<Expr> args,
Expr.ObjectBinding bindings)
return l.stream();
}
}
+
+ abstract class SizeFormatFunc implements Function
+ {
+ protected abstract HumanReadableBytes.UnitSystem getUnitSystem();
+
+ /**
+ * Evaluate given expression
+ * By default, 'precision' is 2 and 'hasSpace' is false
+ */
+ @Override
+ public ExprEval apply(List<Expr> args, Expr.ObjectBinding bindings)
+ {
+ final long bytes = args.get(0).eval(bindings).asLong();
Review comment:
Since we are calling `asLong` without checking `isNumericNull` of the
`ExprEval`, we are ignoring the value of `druid.generic.useDefaultValueForNull`
here, which I think is incorrect.
Thinking out loud, how should this function behave with non-long inputs?
The way this is currently implement:
* Inputs of `ExprType.DOUBLE` will be cast to a `ExprType.LONG` before
conversion.
* For `ExprType.STRING` inputs, if they are number-ish strings, they will be
parsed into long values, but if not `asLong` will always be 0.
I don't know that this behavior is incorrect, I just wanted to call it out
to think about it.
I do think we want to check for `isNumericNull` and return
`ExprEval.of(null)` if `NullHandling.sqlCompatible()` is set, for any input
types.
I see in the SQL operator it looks like it strictly validates that the
inputs are numeric, while Druid native expressions have traditionally been a
bit fast and loose about the inputs they accept and tend to be rather
forgiving, so perhaps this is ok that the behavior here doesn't quite match.
----------------------------------------------------------------
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]
