[jira] [Comment Edited] (CALCITE-3017) Improve null handling of JsonValueExpressionOperator

["Hongze Zhang (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/CALCITE-3017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16827655#comment-16827655 ] 

Hongze Zhang edited comment on CALCITE-3017 at 5/9/19 7:10 AM:
---------------------------------------------------------------

I am about to finish a patch resolving this (the work is at https://github.com/zhztheplayer/calcite/tree/3017). The main approach is to remove the implicit add of calls to {{JsonValueExpressionOperator}}, and use Java method overload instead. This way a dejsonized NULL can be wrapped and represent by a {{JsonValueContext}} object.

A downside of removing implicit calls is that users should implement the implicit behavior by themselves. In a sense this is not quite a bad thing because:

 * It reduces complexity;
 * "Implicit" behavior is reasonable to be considered in a lower level/layer.

Also, some minor refactors/changes done:
* Remove {{JsonApiCommonSyntaxOperator}}, the reason to do this is similar: complexity reduced, and more flexibility gained;
* Move JSON processing functions out from {{SqlFunctions}}, create new one named {{JsonFunctions}};
* Rex2Lix: Add explicit cast to Java type for null literal, to avoid error on calling overloaded methods.


was (Author: zhztheplayer):
I am about to finished a patch resolving this (the work is at https://github.com/zhztheplayer/calcite/tree/3017). The main approach is to remove the implicit add of calls to {{JsonValueExpressionOperator}}, and use Java method overload instead. This way a dejsonized NULL can be wrapped and represent by a {{JsonValueContext}} object.

A downside of removing implicit calls is that users should implement the implicit behavior by themselves. In a sense this is not quite a bad thing because:

 * It reduces complexity;
 * "Implicit" behavior is reasonable to be considered in a lower level/layer.

Also, some minor refactors/changes done:
* Remove {{JsonApiCommonSyntaxOperator}}, the reason to do this is similar: complexity reduced, and more flexibility gained;
* Move JSON processing functions out from {{SqlFunctions}}, create new one named {{JsonFunctions}};
* Rex2Lix: Add explicit cast to Java type for null literal, to avoid error on calling overloaded methods.

> Improve null handling of JsonValueExpressionOperator
> ----------------------------------------------------
>
>                 Key: CALCITE-3017
>                 URL: https://issues.apache.org/jira/browse/CALCITE-3017
>             Project: Calcite
>          Issue Type: Sub-task
>            Reporter: Hongze Zhang
>            Assignee: Hongze Zhang
>            Priority: Major
>              Labels: pull-request-available
>             Fix For: 1.20.0
>
>          Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> In Calcite's implementation, {{JsonValueExpressionOperator}} currently returns a null value no matter the argument is JSON NULL value or SQL NULL value. But in MySQL, some JSON functions behave differently on different null inputs. For instance for a MySQL JSON function {{JSON_STORAGE_SIZE}}, if we execute:
> {code:sql}
> SELECT JSON_STORAGE_SIZE(null), JSON_STORAGE_SIZE('null')
> {code}
> The result should be:
> ||JSON_STORAGE_SIZE(null)||JSON_STORAGE_SIZE('null')||
> |null|2|
> We should improve the operator a bit to support different behaviors.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)