[
https://issues.apache.org/jira/browse/FLINK-40545?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ramin Gharib updated FLINK-40545:
---------------------------------
Description:
{{PARSE_JSON}} and {{TRY_PARSE_JSON}} parse a JSON string into a
{{{}VARIANT{}}}. They are
available in SQL and as {{{}BuiltInFunctionDefinitions{}}}, but unlike almost
every other JSON
function they have no dedicated Table API expression method. Users must fall
back to the
generic {{{}call(){}}}:
{code:java}
call("PARSE_JSON", $("f")) // string name
call(BuiltInFunctionDefinitions.PARSE_JSON, $("f")) // or the definition
{code}
Most JSON functions already expose a fluent method on {{BaseExpressions}} —
{{{}jsonQuote(){}}},
{{{}jsonUnquote(){}}}, {{{}isJson(){}}}, {{{}jsonExists(){}}},
{{{}jsonValue(){}}}, {{{}jsonQuery(){}}}, etc.
{{{}PARSE_JSON{}}}/{{{}TRY_PARSE_JSON{}}} are the exception, which is
inconsistent and hurts
discoverability.
h3. Proposed change
Add the two methods to {{BaseExpressions}} following the existing
{{jsonQuote()}} pattern:
{code:java}
public OutType parseJson() {
return toApiSpecificExpression(unresolvedCall(PARSE_JSON,
objectToExpression(toExpr())));
}
public OutType tryParseJson() {
return toApiSpecificExpression(unresolvedCall(TRY_PARSE_JSON,
objectToExpression(toExpr())));
}
{code}
Usage becomes:
{code:java}
$("f").parseJson() // instead of call("PARSE_JSON", $("f"))
$("f").tryParseJson()
{code}
Also update for parity:
* PyFlink Table API ({{{}flink-python/pyflink/table/expression.py{}}})
* Table API function documentation (JSON functions section)
h3. Context
Surfaced in the FLINK-37926 review (VARIANT-to-constructed casts): the cast
tests use
{{call("PARSE_JSON", ...)}} because no Table API method exists.
was:
{\{PARSE_JSON}} and \{{TRY_PARSE_JSON}} parse a JSON string into a
\{{VARIANT}}. They are
available in SQL and as \{{BuiltInFunctionDefinitions}}, but unlike almost
every other JSON
function they have no dedicated Table API expression method. Users must fall
back to the
generic \{{call()}}:
{code:java}
call("PARSE_JSON", $("f")) // string name
call(BuiltInFunctionDefinitions.PARSE_JSON, $("f")) // or the definition
{code}
Most JSON functions already expose a fluent method on \{{BaseExpressions}} —
\{{jsonQuote()}},
{\{jsonUnquote()}}, \{{isJson()}}, \{{jsonExists()}}, \{{jsonValue()}},
\{{jsonQuery()}}, etc.
{\{PARSE_JSON}}/\{{TRY_PARSE_JSON}} are the exception, which is inconsistent
and hurts
discoverability.
h3. Proposed change
Add the two methods to \{{BaseExpressions}} following the existing
\{{jsonQuote()}} pattern:
{code:java}
public OutType parseJson() {
return toApiSpecificExpression(unresolvedCall(PARSE_JSON,
objectToExpression(toExpr())));
}
public OutType tryParseJson() {
return toApiSpecificExpression(unresolvedCall(TRY_PARSE_JSON,
objectToExpression(toExpr())));
}
{code}
Usage becomes:
{code:java}
$("f").parseJson() // instead of call("PARSE_JSON", $("f"))
$("f").tryParseJson()
{code}
Also update for parity:
* PyFlink Table API (\{{flink-python/pyflink/table/expression.py}})
* Table API function documentation (JSON functions section)
h3. Context
Surfaced in the FLINK-37926 review (VARIANT-to-constructed casts): the cast
tests use
{\{call("PARSE_JSON", ...)}} because no Table API method exists.
{code}
> Add parseJson() and tryParseJson() Table API expression methods
> ---------------------------------------------------------------
>
> Key: FLINK-40545
> URL: https://issues.apache.org/jira/browse/FLINK-40545
> Project: Flink
> Issue Type: Improvement
> Reporter: Ramin Gharib
> Assignee: Ramin Gharib
> Priority: Major
>
> {{PARSE_JSON}} and {{TRY_PARSE_JSON}} parse a JSON string into a
> {{{}VARIANT{}}}. They are
> available in SQL and as {{{}BuiltInFunctionDefinitions{}}}, but unlike almost
> every other JSON
> function they have no dedicated Table API expression method. Users must fall
> back to the
> generic {{{}call(){}}}:
> {code:java}
> call("PARSE_JSON", $("f")) // string name
> call(BuiltInFunctionDefinitions.PARSE_JSON, $("f")) // or the definition
> {code}
> Most JSON functions already expose a fluent method on {{BaseExpressions}} —
> {{{}jsonQuote(){}}},
> {{{}jsonUnquote(){}}}, {{{}isJson(){}}}, {{{}jsonExists(){}}},
> {{{}jsonValue(){}}}, {{{}jsonQuery(){}}}, etc.
> {{{}PARSE_JSON{}}}/{{{}TRY_PARSE_JSON{}}} are the exception, which is
> inconsistent and hurts
> discoverability.
> h3. Proposed change
> Add the two methods to {{BaseExpressions}} following the existing
> {{jsonQuote()}} pattern:
> {code:java}
> public OutType parseJson() {
> return toApiSpecificExpression(unresolvedCall(PARSE_JSON,
> objectToExpression(toExpr())));
> }
> public OutType tryParseJson() {
> return toApiSpecificExpression(unresolvedCall(TRY_PARSE_JSON,
> objectToExpression(toExpr())));
> }
> {code}
> Usage becomes:
> {code:java}
> $("f").parseJson() // instead of call("PARSE_JSON", $("f"))
> $("f").tryParseJson()
> {code}
> Also update for parity:
> * PyFlink Table API ({{{}flink-python/pyflink/table/expression.py{}}})
> * Table API function documentation (JSON functions section)
> h3. Context
> Surfaced in the FLINK-37926 review (VARIANT-to-constructed casts): the cast
> tests use
> {{call("PARSE_JSON", ...)}} because no Table API method exists.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
