VasShabu commented on code in PR #28850:
URL: https://github.com/apache/flink/pull/28850#discussion_r3705564946
##########
flink-table/flink-table-runtime/src/main/java/org/apache/flink/table/runtime/functions/SqlJsonUtils.java:
##########
@@ -446,6 +459,107 @@ private static Object dejsonize(String input) {
return JSON_PATH_JSON_PROVIDER.parse(input);
}
+ /**
+ * Returns an upper-case flag describing the type of the parsed JSON
value, mirroring Calcite's
+ * {@code JsonFunctions.jsonType}.
+ *
+ * <p>JSON's grammar cannot express a date, and it has a single number
rule with no width, so
+ * {@code DATE} and {@code FLOAT} cannot be read off the Java type the
parser produces: a date
+ * arrives as a {@link String}, and every non-integral number arrives as a
{@link BigDecimal}
+ * (the shared mapper enables {@code USE_BIG_DECIMAL_FOR_FLOATS}). Both
flags are therefore
+ * inferred from the value itself, which is a deliberate Flink extension
beyond Calcite:
+ *
+ * <ul>
+ * <li>{@code DATE} for a string that is exactly a {@code yyyy-MM-dd}
calendar date, e.g.
+ * {@code "2015-01-01"}, which is the form the JSON format uses to
read a {@code DATE}
+ * column. Nothing else counts. This is stricter than {@code CAST(x
AS DATE)}, which also
+ * coerces {@code 2015-1-1}, {@code 2015-01} and {@code 2015}; those
are
+ * recognition-unsafe here, since {@code "2015"} is a perfectly
ordinary string.
+ * Date-times stay {@code STRING} in every spelling: there is no
timestamp flag to return,
+ * and answering {@code DATE} for a value carrying a time of day
would be worse than
+ * saying nothing. Flink has no single date-time spelling to defer
to either — {@code
+ * CAST}/{@code TO_TIMESTAMP} accept only a space separator, the
JSON format accepts a
+ * space or a {@code T} depending on its {@code
timestamp-format.standard} option, and
+ * variants use {@code T} — so recognition would have to depend on a
per-table option this
+ * function cannot see.
+ * <li>{@code FLOAT} for a number that is exactly representable in 32
bits, e.g. {@code 1.5};
+ * anything needing more precision, such as {@code 11.1}, stays
{@code DOUBLE}.
+ * </ul>
+ *
+ * <p>Note that these flags describe an inferred type that the other JSON
functions do not
+ * share: {@code JSON_VALUE} still returns {@code "2015-01-01"} as a
string.
+ */
+ public static String jsonType(final JsonValueContext parsedInput) {
+ // The parsed context is shared with JSON_VALUE / JSON_QUERY over the
same input, and those
+ // assign it only inside their own args-not-null guard. A NULL path
argument in a preceding
+ // call therefore leaves it null here even though the input itself was
fine. Report NULL
+ // instead of failing, which is how those functions already degrade in
the same situation
+ // (their NPE is swallowed by jsonApiCommonSyntax and falls through to
ON ERROR -> NULL).
+ // A follow-up fixes the sharing for all JSON functions.
+ if (parsedInput == null || parsedInput.hasException()) {
+ return null;
+ }
+ final Object val = parsedInput.obj;
+ if (val instanceof Integer) {
+ return "INTEGER";
+ } else if (val instanceof String) {
+ return isYyyyMmDdDate((String) val) ? "DATE" : "STRING";
+ } else if (val instanceof BigDecimal) {
+ return isExactFloat((BigDecimal) val) ? "FLOAT" : "DOUBLE";
+ } else if (val instanceof Double) {
+ return "DOUBLE";
+ } else if (val instanceof Long || val instanceof BigInteger) {
+ return "LONG";
+ } else if (val instanceof Boolean) {
+ return "BOOLEAN";
+ } else if (val instanceof Map) {
+ return "OBJECT";
+ } else if (val instanceof Collection) {
+ return "ARRAY";
+ } else if (val == null) {
+ return "NULL";
+ }
+ return null;
Review Comment:
I needed a way to differentiate invalid JSON to a literal json null. So I
decided to make it so that
invalid json -> null
null literal -> "NULL"
let me know if I should change this implementation
--
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]
