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:
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 will always be 0 if they are not parseable
as numbers, since we are calling `asLong` without checking `isNumericNull` of
the `ExprEval`, so we are ignoring the value of
`druid.generic.useDefaultValueForNull`.
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.
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.
##########
File path: docs/querying/sql.md
##########
@@ -563,6 +563,9 @@ The [DataSketches
extension](../development/extensions-core/datasketches-extensi
|`COALESCE(value1, value2, ...)`|Returns the first value that is neither NULL
nor empty string.|
|`NVL(expr,expr-for-null)`|Returns 'expr-for-null' if 'expr' is null (or empty
string for string type).|
|`BLOOM_FILTER_TEST(<expr>, <serialized-filter>)`|Returns true if the value is
contained in a Base64-serialized bloom filter. See the [Bloom filter
extension](../development/extensions-core/bloom-filter.html) documentation for
additional details.|
+|`BINARY_BYTE_FORMAT(value, [precision])`|Returns the value in human-readable
[IEC](https://en.wikipedia.org/wiki/Binary_prefix) format. Supported unit
suffix: `B`, `KiB`, `MiB`, `GiB`, `TiB`, `PiB`, `EiB`. `precision` must be in
the range of [0,3] (default: 2).|
+|`DECIMAL_BYTE_FORMAT(value, [precision])`|Returns the value in human-readable
[SI](https://en.wikipedia.org/wiki/Binary_prefix) format. Supported unit
suffix: `B`, `KB`, `MB`, `GB`, `TB`, `PB`, `EB`. `precision` must be in the
range of [0,3] (default: 2).|
+|`DECIMAL_FORMAT(value, [precision])`|Returns the value in human-readable SI
format. Supported unit suffix: `K`, `M`, `G`, `T`, `P`, `E`. `precision` must
be in the range of [0,3] (default: 2).|
Review comment:
Should these docs live with the 'numeric' functions? I suppose here is
ok too...
----------------------------------------------------------------
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]
