[jira] [Comment Edited] (CALCITE-4785) The parser allows multiple ON ERROR or ON EMPTY clauses for JSON_QUERY and JSON_VALUE
[
https://issues.apache.org/jira/browse/CALCITE-4785?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17417104#comment-17417104
]
Hongze Zhang edited comment on CALCITE-4785 at 9/19/21, 2:21 AM:
-
It should be feasible to add some extra checks to SqlJsonValueFunction and
SqlJsonQueryFunction (I see we used to have some then removed in some refactor
commits. Although this kind of check was too never included). Just went through
the current Parser code and it looks fine to me.
was (Author: zhztheplayer):
It should be feasible to add some extra checks to SqlJsonValueFunction and
SqlJsonQueryFunction (I see we used to have some then removed in some
refactors. Although this kind of check was too not included). Just went through
the current Parser code and it looks fine to me.
> The parser allows multiple ON ERROR or ON EMPTY clauses for JSON_QUERY and
> JSON_VALUE
> -
>
> Key: CALCITE-4785
> URL: https://issues.apache.org/jira/browse/CALCITE-4785
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.27.0
>Reporter: Viliam Durina
>Priority: Minor
> Attachments: screenshot-1.png
>
>
> The following expression parses succesfully:
> {{JSON_VALUE('bad-json', '$' DEFAULT 1 ON ERROR DEFAULT 2 ON ERROR)}}
> The 2nd ON ERROR clause overrides the 1st one and the expression returns
> {{2}}. Instead, an error should be thrown.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4785) The parser allows multiple ON ERROR or ON EMPTY clauses for JSON_QUERY and JSON_VALUE
[
https://issues.apache.org/jira/browse/CALCITE-4785?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17417104#comment-17417104
]
Hongze Zhang commented on CALCITE-4785:
---
It should be feasible to add some extra checks to SqlJsonValueFunction and
SqlJsonQueryFunction. Just went through the current Parser code and it looks
fine to me.
> The parser allows multiple ON ERROR or ON EMPTY clauses for JSON_QUERY and
> JSON_VALUE
> -
>
> Key: CALCITE-4785
> URL: https://issues.apache.org/jira/browse/CALCITE-4785
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.27.0
>Reporter: Viliam Durina
>Priority: Minor
> Attachments: screenshot-1.png
>
>
> The following expression parses succesfully:
> {{JSON_VALUE('bad-json', '$' DEFAULT 1 ON ERROR DEFAULT 2 ON ERROR)}}
> The 2nd ON ERROR clause overrides the 1st one and the expression returns
> {{2}}. Instead, an error should be thrown.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-3243) Incomplete validation of operands in JSON functions
[
https://issues.apache.org/jira/browse/CALCITE-3243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16990801#comment-16990801
]
Hongze Zhang commented on CALCITE-3243:
---
Thanks for working on this issue [~wangm92] and [~zabetak]. And you might
already notice that CALCITE-2869 is more or less a blocker to this one.
Currently we don't ban 'SqlTypeFamily.ANY' as an operand type because JSON
functions accepts not only a plain string but also a
SqlJsonValueExpressionOprator[1], which is of return type 'SqlTypeFamily.ANY'.
In the fix of CALCITE-2869 we should ideally turn SqlJsonValueExpressionOprator
to return 'SqlTypeFamily.JSON' or something, then strengthen the operand
validation to solve this problem.
[1]
[https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/sql/fun/SqlJsonValueExpressionOperator.java]
> Incomplete validation of operands in JSON functions
> -
>
> Key: CALCITE-3243
> URL: https://issues.apache.org/jira/browse/CALCITE-3243
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.20.0
>Reporter: Stamatis Zampetakis
>Assignee: Matt Wang
>Priority: Major
> Labels: pull-request-available
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> The operands of various JSON functions are not validated correctly.
> Consider for instance the {{JSON_VALUE}} function and the following calls:
> {code:sql}
> json_value('{\"foo\":100}', 'strict $.foo')"
> json_value(1, 'strict $.foo')"
> json_value(TRUE, 'strict $.foo')"
> {code}
> The first call is legal but the next are not; if I am not wrong the operands
> should be always CHAR or VARCHAR literals which is not the case above.
> Queries involving such calls fail at runtime when compiling generated code. I
> guess that such kind of problems should be captured by the validator and we
> should not even arrive at the code generation step.
> The problems can be easily reproduced by adding such calls in the
> {{SqlOperatorBaseTest}}.
> The problem does not only affect {{JSON_VALUE}} but other JSON functions
> (such as {{JSON_QUERY}} etc.) as well.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-2804) Druid adapter: Cast does not work when casting to timestamp
[
https://issues.apache.org/jira/browse/CALCITE-2804?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16863282#comment-16863282
]
Hongze Zhang commented on CALCITE-2804:
---
Thanks [~jszeluga].
And thanks [~zabetak] for the suggestion. I have to open a new
[PR|https://github.com/apache/calcite/pull/1270], and review is needed because
I am not able to test the PR by myself. Could you or someone please review it?
Thanks a lot.
> Druid adapter: Cast does not work when casting to timestamp
> ---
>
> Key: CALCITE-2804
> URL: https://issues.apache.org/jira/browse/CALCITE-2804
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.18.0
>Reporter: Justin Szeluga
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.20.0
>
> Time Spent: 4.5h
> Remaining Estimate: 0h
>
> When trying to execute a simple statement of
> {code:java}
> select cast("__time" as timestamp) from my_datasource limit 10;{code}
> the query fails with a 500 error
>
> {code:java}
> Caused by: java.io.IOException: Server returned HTTP response code: 500 for
> URL: http://localhost:58082/druid/v2/?pretty
> at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(Unknown Source)
> at sun.net.www.protocol.http.HttpURLConnection.getInputStream(Unknown Source)
> at org.apache.calcite.runtime.HttpUtils.executeMethod(HttpUtils.java:137)
> at org.apache.calcite.runtime.HttpUtils.post(HttpUtils.java:110)
> at
> org.apache.calcite.adapter.druid.DruidConnectionImpl.request(DruidConnectionImpl.java:109)
> ... 29 more
> {code}
> because the JSON generated is incorrect. Here is the generated JSON
>
>
> {code:java}
> {
> "queryType": "scan",
> "dataSource": "my_datasource",
> "intervals": [
> "1900-01-01T00:00:00.000Z/3000-01-01T00:00:00.000Z"
> ],
> "virtualColumns": [
> {
> "type": "expression",
> "name": "vc",
> "expression":
> "timestamp_parse(timestamp_format(\"__time\",'-MM-dd\\u0027T\\u0027HH:mm:ss.SSS\\u0027Z\\u0027','America/New_York'),'','UTC')",
> "outputType": "LONG"
> }
> ],
> "columns": [
> "vc"
> ],
> "resultFormat": "compactedList",
> "limit": 10
> }
> {code}
> There are two problems. -First, the "__time" dimension is not formatted
> correctly in timestamp_format. The escaped quotes need to be removed.-
> Also, the call to timestamp_parse is incorrect. If a timezone is going to be
> provided then a date time format needs to be provided as well. Currently, it
> is only empty string
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2804) Druid adapter: Cast does not work when casting to timestamp
[
https://issues.apache.org/jira/browse/CALCITE-2804?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16863235#comment-16863235
]
Hongze Zhang commented on CALCITE-2804:
---
Hi [~jszeluga], I see there are some comments in PR haven't been addressed yet.
Since the issue might be a blocker of Calcite's next release I'd like to add
some changes on top of your work if you don't mind. (I have to open a new PR :)
)
> Druid adapter: Cast does not work when casting to timestamp
> ---
>
> Key: CALCITE-2804
> URL: https://issues.apache.org/jira/browse/CALCITE-2804
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.18.0
>Reporter: Justin Szeluga
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.20.0
>
> Time Spent: 4h
> Remaining Estimate: 0h
>
> When trying to execute a simple statement of
> {code:java}
> select cast("__time" as timestamp) from my_datasource limit 10;{code}
> the query fails with a 500 error
>
> {code:java}
> Caused by: java.io.IOException: Server returned HTTP response code: 500 for
> URL: http://localhost:58082/druid/v2/?pretty
> at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(Unknown Source)
> at sun.net.www.protocol.http.HttpURLConnection.getInputStream(Unknown Source)
> at org.apache.calcite.runtime.HttpUtils.executeMethod(HttpUtils.java:137)
> at org.apache.calcite.runtime.HttpUtils.post(HttpUtils.java:110)
> at
> org.apache.calcite.adapter.druid.DruidConnectionImpl.request(DruidConnectionImpl.java:109)
> ... 29 more
> {code}
> because the JSON generated is incorrect. Here is the generated JSON
>
>
> {code:java}
> {
> "queryType": "scan",
> "dataSource": "my_datasource",
> "intervals": [
> "1900-01-01T00:00:00.000Z/3000-01-01T00:00:00.000Z"
> ],
> "virtualColumns": [
> {
> "type": "expression",
> "name": "vc",
> "expression":
> "timestamp_parse(timestamp_format(\"__time\",'-MM-dd\\u0027T\\u0027HH:mm:ss.SSS\\u0027Z\\u0027','America/New_York'),'','UTC')",
> "outputType": "LONG"
> }
> ],
> "columns": [
> "vc"
> ],
> "resultFormat": "compactedList",
> "limit": 10
> }
> {code}
> There are two problems. -First, the "__time" dimension is not formatted
> correctly in timestamp_format. The escaped quotes need to be removed.-
> Also, the call to timestamp_parse is incorrect. If a timezone is going to be
> provided then a date time format needs to be provided as well. Currently, it
> is only empty string
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2804) Druid adapter: Cast does not work when casting to timestamp
[
https://issues.apache.org/jira/browse/CALCITE-2804?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16859381#comment-16859381
]
Hongze Zhang commented on CALCITE-2804:
---
Thanks [~jszeluga] I know what happens now.
PR [https://github.com/apache/calcite/pull/1262] looks good, +1 if test passed.
A non-blocker comment: is it really required to check whole generated plan for
the test case? Can we only check the expression:
{quote}timestamp_parse(timestamp_format("__time",'-MM-dd\u0027T\u0027HH:mm:ss.SSS\u0027Z\u0027','America/New_York'),'-MM-dd\u0027T\u0027HH:mm:ss.SSS\u0027Z\u0027','UTC')
{quote}
using a simple string contains predicate? This way the code will be simpler and
use of {{DruidAdapterIT#druidChecker}} can be avoided.
> Druid adapter: Cast does not work when casting to timestamp
> ---
>
> Key: CALCITE-2804
> URL: https://issues.apache.org/jira/browse/CALCITE-2804
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.18.0
>Reporter: Justin Szeluga
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.20.0
>
> Time Spent: 2h 50m
> Remaining Estimate: 0h
>
> When trying to execute a simple statement of
> {code:java}
> select cast("__time" as timestamp) from my_datasource limit 10;{code}
> the query fails with a 500 error
>
> {code:java}
> Caused by: java.io.IOException: Server returned HTTP response code: 500 for
> URL: http://localhost:58082/druid/v2/?pretty
> at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(Unknown Source)
> at sun.net.www.protocol.http.HttpURLConnection.getInputStream(Unknown Source)
> at org.apache.calcite.runtime.HttpUtils.executeMethod(HttpUtils.java:137)
> at org.apache.calcite.runtime.HttpUtils.post(HttpUtils.java:110)
> at
> org.apache.calcite.adapter.druid.DruidConnectionImpl.request(DruidConnectionImpl.java:109)
> ... 29 more
> {code}
> because the JSON generated is incorrect. Here is the generated JSON
>
>
> {code:java}
> {
> "queryType": "scan",
> "dataSource": "my_datasource",
> "intervals": [
> "1900-01-01T00:00:00.000Z/3000-01-01T00:00:00.000Z"
> ],
> "virtualColumns": [
> {
> "type": "expression",
> "name": "vc",
> "expression":
> "timestamp_parse(timestamp_format(\"__time\",'-MM-dd\\u0027T\\u0027HH:mm:ss.SSS\\u0027Z\\u0027','America/New_York'),'','UTC')",
> "outputType": "LONG"
> }
> ],
> "columns": [
> "vc"
> ],
> "resultFormat": "compactedList",
> "limit": 10
> }
> {code}
> There are two problems. -First, the "__time" dimension is not formatted
> correctly in timestamp_format. The escaped quotes need to be removed.-
> Also, the call to timestamp_parse is incorrect. If a timezone is going to be
> provided then a date time format needs to be provided as well. Currently, it
> is only empty string
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2804) Druid adapter: Cast does not work when casting to timestamp
[
https://issues.apache.org/jira/browse/CALCITE-2804?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16859316#comment-16859316
]
Hongze Zhang commented on CALCITE-2804:
---
Sorry I was again not able to install the VMs. As the issue might become a
blocker of 1.20.0, if no one else is working on a fix (could someone help?
thanks a lot), my intuition is to change the expected output to match the
actual. It seems to be safe.
> Druid adapter: Cast does not work when casting to timestamp
> ---
>
> Key: CALCITE-2804
> URL: https://issues.apache.org/jira/browse/CALCITE-2804
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.18.0
>Reporter: Justin Szeluga
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.20.0
>
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> When trying to execute a simple statement of
> {code:java}
> select cast("__time" as timestamp) from my_datasource limit 10;{code}
> the query fails with a 500 error
>
> {code:java}
> Caused by: java.io.IOException: Server returned HTTP response code: 500 for
> URL: http://localhost:58082/druid/v2/?pretty
> at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(Unknown Source)
> at sun.net.www.protocol.http.HttpURLConnection.getInputStream(Unknown Source)
> at org.apache.calcite.runtime.HttpUtils.executeMethod(HttpUtils.java:137)
> at org.apache.calcite.runtime.HttpUtils.post(HttpUtils.java:110)
> at
> org.apache.calcite.adapter.druid.DruidConnectionImpl.request(DruidConnectionImpl.java:109)
> ... 29 more
> {code}
> because the JSON generated is incorrect. Here is the generated JSON
>
>
> {code:java}
> {
> "queryType": "scan",
> "dataSource": "my_datasource",
> "intervals": [
> "1900-01-01T00:00:00.000Z/3000-01-01T00:00:00.000Z"
> ],
> "virtualColumns": [
> {
> "type": "expression",
> "name": "vc",
> "expression":
> "timestamp_parse(timestamp_format(\"__time\",'-MM-dd\\u0027T\\u0027HH:mm:ss.SSS\\u0027Z\\u0027','America/New_York'),'','UTC')",
> "outputType": "LONG"
> }
> ],
> "columns": [
> "vc"
> ],
> "resultFormat": "compactedList",
> "limit": 10
> }
> {code}
> There are two problems. -First, the "__time" dimension is not formatted
> correctly in timestamp_format. The escaped quotes need to be removed.-
> Also, the call to timestamp_parse is incorrect. If a timezone is going to be
> provided then a date time format needs to be provided as well. Currently, it
> is only empty string
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2804) Druid adapter: Cast does not work when casting to timestamp
[
https://issues.apache.org/jira/browse/CALCITE-2804?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16859112#comment-16859112
]
Hongze Zhang commented on CALCITE-2804:
---
[~jszeluga] - Do you have any comments on the issue?
> Druid adapter: Cast does not work when casting to timestamp
> ---
>
> Key: CALCITE-2804
> URL: https://issues.apache.org/jira/browse/CALCITE-2804
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.18.0
>Reporter: Justin Szeluga
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.20.0
>
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> When trying to execute a simple statement of
> {code:java}
> select cast("__time" as timestamp) from my_datasource limit 10;{code}
> the query fails with a 500 error
>
> {code:java}
> Caused by: java.io.IOException: Server returned HTTP response code: 500 for
> URL: http://localhost:58082/druid/v2/?pretty
> at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(Unknown Source)
> at sun.net.www.protocol.http.HttpURLConnection.getInputStream(Unknown Source)
> at org.apache.calcite.runtime.HttpUtils.executeMethod(HttpUtils.java:137)
> at org.apache.calcite.runtime.HttpUtils.post(HttpUtils.java:110)
> at
> org.apache.calcite.adapter.druid.DruidConnectionImpl.request(DruidConnectionImpl.java:109)
> ... 29 more
> {code}
> because the JSON generated is incorrect. Here is the generated JSON
>
>
> {code:java}
> {
> "queryType": "scan",
> "dataSource": "my_datasource",
> "intervals": [
> "1900-01-01T00:00:00.000Z/3000-01-01T00:00:00.000Z"
> ],
> "virtualColumns": [
> {
> "type": "expression",
> "name": "vc",
> "expression":
> "timestamp_parse(timestamp_format(\"__time\",'-MM-dd\\u0027T\\u0027HH:mm:ss.SSS\\u0027Z\\u0027','America/New_York'),'','UTC')",
> "outputType": "LONG"
> }
> ],
> "columns": [
> "vc"
> ],
> "resultFormat": "compactedList",
> "limit": 10
> }
> {code}
> There are two problems. -First, the "__time" dimension is not formatted
> correctly in timestamp_format. The escaped quotes need to be removed.-
> Also, the call to timestamp_parse is incorrect. If a timezone is going to be
> provided then a date time format needs to be provided as well. Currently, it
> is only empty string
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2804) Druid adapter: Cast does not work when casting to timestamp
[
https://issues.apache.org/jira/browse/CALCITE-2804?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16859110#comment-16859110
]
Hongze Zhang commented on CALCITE-2804:
---
It is weird. I noticed the quote difference but I see in code we already used
single quote[1]. So I thought it was related to display of the test output.
Regarding "__time". I believe we still need the double quote around column
name. See discussion[2] in PR. So JIRA description about this point is no
longer valid.
I'll try to install the IT VMs (it may take some time), but not sure it can
work as expected, since I remember that I was blocked by GFW when I install
them last time. :(
[1]
[https://github.com/apache/calcite/pull/1014/files#diff-88c776102776d0dfedaf74e4be27854fR590]
[2] [https://github.com/apache/calcite/pull/1014#discussion_r256784061]
> Druid adapter: Cast does not work when casting to timestamp
> ---
>
> Key: CALCITE-2804
> URL: https://issues.apache.org/jira/browse/CALCITE-2804
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.18.0
>Reporter: Justin Szeluga
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.20.0
>
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> When trying to execute a simple statement of
> {code:java}
> select cast("__time" as timestamp) from my_datasource limit 10;{code}
> the query fails with a 500 error
>
> {code:java}
> Caused by: java.io.IOException: Server returned HTTP response code: 500 for
> URL: http://localhost:58082/druid/v2/?pretty
> at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(Unknown Source)
> at sun.net.www.protocol.http.HttpURLConnection.getInputStream(Unknown Source)
> at org.apache.calcite.runtime.HttpUtils.executeMethod(HttpUtils.java:137)
> at org.apache.calcite.runtime.HttpUtils.post(HttpUtils.java:110)
> at
> org.apache.calcite.adapter.druid.DruidConnectionImpl.request(DruidConnectionImpl.java:109)
> ... 29 more
> {code}
> because the JSON generated is incorrect. Here is the generated JSON
>
>
> {code:java}
> {
> "queryType": "scan",
> "dataSource": "my_datasource",
> "intervals": [
> "1900-01-01T00:00:00.000Z/3000-01-01T00:00:00.000Z"
> ],
> "virtualColumns": [
> {
> "type": "expression",
> "name": "vc",
> "expression":
> "timestamp_parse(timestamp_format(\"__time\",'-MM-dd\\u0027T\\u0027HH:mm:ss.SSS\\u0027Z\\u0027','America/New_York'),'','UTC')",
> "outputType": "LONG"
> }
> ],
> "columns": [
> "vc"
> ],
> "resultFormat": "compactedList",
> "limit": 10
> }
> {code}
> There are two problems. -First, the "__time" dimension is not formatted
> correctly in timestamp_format. The escaped quotes need to be removed.-
> Also, the call to timestamp_parse is incorrect. If a timezone is going to be
> provided then a date time format needs to be provided as well. Currently, it
> is only empty string
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2804) Druid adapter: Cast does not work when casting to timestamp
[
https://issues.apache.org/jira/browse/CALCITE-2804?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16858810#comment-16858810
]
Hongze Zhang commented on CALCITE-2804:
---
[~michaelmior], [~zabetak] - thanks and sorry I am currently not able to run
the integration test VMs on my PC, so I can test it by my own at this time.
By the way, Stamatis, do you have a chance to see what's the difference between
"expected" and "actual"? I failed using text compare tools to find some clues.
I have a feeling that the issue might not be a major one and we can just modify
expected query text to match the actual.
> Druid adapter: Cast does not work when casting to timestamp
> ---
>
> Key: CALCITE-2804
> URL: https://issues.apache.org/jira/browse/CALCITE-2804
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.18.0
>Reporter: Justin Szeluga
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.20.0
>
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> When trying to execute a simple statement of
> {code:java}
> select cast("__time" as timestamp) from my_datasource limit 10;{code}
> the query fails with a 500 error
>
> {code:java}
> Caused by: java.io.IOException: Server returned HTTP response code: 500 for
> URL: http://localhost:58082/druid/v2/?pretty
> at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(Unknown Source)
> at sun.net.www.protocol.http.HttpURLConnection.getInputStream(Unknown Source)
> at org.apache.calcite.runtime.HttpUtils.executeMethod(HttpUtils.java:137)
> at org.apache.calcite.runtime.HttpUtils.post(HttpUtils.java:110)
> at
> org.apache.calcite.adapter.druid.DruidConnectionImpl.request(DruidConnectionImpl.java:109)
> ... 29 more
> {code}
> because the JSON generated is incorrect. Here is the generated JSON
>
>
> {code:java}
> {
> "queryType": "scan",
> "dataSource": "my_datasource",
> "intervals": [
> "1900-01-01T00:00:00.000Z/3000-01-01T00:00:00.000Z"
> ],
> "virtualColumns": [
> {
> "type": "expression",
> "name": "vc",
> "expression":
> "timestamp_parse(timestamp_format(\"__time\",'-MM-dd\\u0027T\\u0027HH:mm:ss.SSS\\u0027Z\\u0027','America/New_York'),'','UTC')",
> "outputType": "LONG"
> }
> ],
> "columns": [
> "vc"
> ],
> "resultFormat": "compactedList",
> "limit": 10
> }
> {code}
> There are two problems. -First, the "__time" dimension is not formatted
> correctly in timestamp_format. The escaped quotes need to be removed.-
> Also, the call to timestamp_parse is incorrect. If a timezone is going to be
> provided then a date time format needs to be provided as well. Currently, it
> is only empty string
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-3073) Support to consume from timestamp in KafkaAdapter
[
https://issues.apache.org/jira/browse/CALCITE-3073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16858056#comment-16858056
]
Hongze Zhang commented on CALCITE-3073:
---
A naive question: Then what should be implemented for this issue? By reading
the issue description:
{quote}With support of from/to timestamp/offset, it's more flexible for users
to query a specific range.
{quote}
And the comment in PR:
{quote}Given a query like SELECT * FROM KAFKA_TABLE WHERE KAFKA_TIMESTAMP >
CURRENT_TIMESTAMP-1, KafkaAdapter would take the filter clause KAFKA_TIMESTAMP
> CURRENT_TIMESTAMP-1 directly.
{quote}
Didn't we already support SQL like {{SELECT STREAM * FROM KAFKA_TABLE WHERE
MSG_TIMESTAMP > CURRENT_TIMESTAMP - 1}} in Kafka adaptor (Maybe tweaking on
data types is needed)? Or the topic is more about performance improvement?
> Support to consume from timestamp in KafkaAdapter
> -
>
> Key: CALCITE-3073
> URL: https://issues.apache.org/jira/browse/CALCITE-3073
> Project: Calcite
> Issue Type: Improvement
> Components: kafka-adapter
>Reporter: Xu Mingmin
>Assignee: Matt Wang
>Priority: Major
> Labels: pull-request-available
> Time Spent: 3h 40m
> Remaining Estimate: 0h
>
> Currently the KafkaAdapter consumes data from default
> offset(latest/earliest/last_offset) and runs forever. With support of from/to
> timestamp/offset, it's more flexible for users to query a specific range.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-3073) Support to consume from timestamp in KafkaAdapter
[
https://issues.apache.org/jira/browse/CALCITE-3073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16857848#comment-16857848
]
Hongze Zhang commented on CALCITE-3073:
---
I'am a little confused with the two columns, the new {{KAFKA_TIMESTAMP}} and
the existing {{MSG_TIMESTAMP}} (sorry I'm not a Kafka expert :)). If we have to
provide a different timestamp column, hopefully we can make them well
documented so that users know which one they should use.
> Support to consume from timestamp in KafkaAdapter
> -
>
> Key: CALCITE-3073
> URL: https://issues.apache.org/jira/browse/CALCITE-3073
> Project: Calcite
> Issue Type: Improvement
> Components: kafka-adapter
>Reporter: Xu Mingmin
>Assignee: Matt Wang
>Priority: Major
> Labels: pull-request-available
> Time Spent: 3h 40m
> Remaining Estimate: 0h
>
> Currently the KafkaAdapter consumes data from default
> offset(latest/earliest/last_offset) and runs forever. With support of from/to
> timestamp/offset, it's more flexible for users to query a specific range.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2906) Record DOT extension does not distinguish between simple and compound identifiers
[
https://issues.apache.org/jira/browse/CALCITE-2906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16857835#comment-16857835
]
Hongze Zhang commented on CALCITE-2906:
---
Marked fix version as 1.21.0.
> Record DOT extension does not distinguish between simple and compound
> identifiers
> -
>
> Key: CALCITE-2906
> URL: https://issues.apache.org/jira/browse/CALCITE-2906
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Rong Rong
>Assignee: Danny Chan
>Priority: Major
> Fix For: 1.21.0
>
>
> Currently the DOT extensions only supports Simple Identifiers:
> For example:
> * *{{tbl.foo(0).col.bar}}* is parsed as: *{{((`TBL`.`FOO`(0).`COL`).`BAR`)}}*
> However, this is not the case in regular Expression field, for example:
> * *{{tbl.col.bar}}* is parsed as: *{{`TBL`.`COL`.`BAR`}}*
> Parser should support both compound identifier, and simple identifier chain
> after a record type SqlNode.
> Similarly, parsing should also be consistent for other types of expression,
> for example
> * *{{tbl.arr[0].foo.bar}}* is currently parsed as:
> *{{((`TBL`.`ARR`[0].`FOO`).`BAR`)}}*
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CALCITE-2906) Record DOT extension does not distinguish between simple and compound identifiers
[
https://issues.apache.org/jira/browse/CALCITE-2906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hongze Zhang updated CALCITE-2906:
--
Fix Version/s: 1.21.0
> Record DOT extension does not distinguish between simple and compound
> identifiers
> -
>
> Key: CALCITE-2906
> URL: https://issues.apache.org/jira/browse/CALCITE-2906
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Rong Rong
>Assignee: Danny Chan
>Priority: Major
> Fix For: 1.21.0
>
>
> Currently the DOT extensions only supports Simple Identifiers:
> For example:
> * *{{tbl.foo(0).col.bar}}* is parsed as: *{{((`TBL`.`FOO`(0).`COL`).`BAR`)}}*
> However, this is not the case in regular Expression field, for example:
> * *{{tbl.col.bar}}* is parsed as: *{{`TBL`.`COL`.`BAR`}}*
> Parser should support both compound identifier, and simple identifier chain
> after a record type SqlNode.
> Similarly, parsing should also be consistent for other types of expression,
> for example
> * *{{tbl.arr[0].foo.bar}}* is currently parsed as:
> *{{((`TBL`.`ARR`[0].`FOO`).`BAR`)}}*
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-3073) Support both from/to timestamp/offset in KafkaAdapter
[ https://issues.apache.org/jira/browse/CALCITE-3073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16857627#comment-16857627 ] Hongze Zhang commented on CALCITE-3073: --- > Agree, let's focus on timestamp support here. Should we update JIRA title accordingly? > Support both from/to timestamp/offset in KafkaAdapter > - > > Key: CALCITE-3073 > URL: https://issues.apache.org/jira/browse/CALCITE-3073 > Project: Calcite > Issue Type: Improvement > Components: kafka-adapter >Reporter: Xu Mingmin >Assignee: Matt Wang >Priority: Major > Labels: pull-request-available > Time Spent: 2h 20m > Remaining Estimate: 0h > > Currently the KafkaAdapter consumes data from default > offset(latest/earliest/last_offset) and runs forever. With support of from/to > timestamp/offset, it's more flexible for users to query a specific range. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (CALCITE-2870) Support for JSON query quotes behavior
[
https://issues.apache.org/jira/browse/CALCITE-2870?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hongze Zhang reassigned CALCITE-2870:
-
Assignee: Ritesh
> Support for JSON query quotes behavior
> --
>
> Key: CALCITE-2870
> URL: https://issues.apache.org/jira/browse/CALCITE-2870
> Project: Calcite
> Issue Type: Sub-task
>Reporter: Hongze Zhang
>Assignee: Ritesh
>Priority: Major
> Labels: pull-request-available
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> Syntax of {{JSON query quotes behavior}}:
> {code:java}
> ::= KEEP | OMIT
> {code}
> ISO/IEC 9075-6[1] does not provide detail information about this clause.
> Where it seems that DB2 has an implementation[2] for it, for controlling
> whether to remove quotes from a scalar string.
> [1]
> [http://standards.iso.org/ittf/PubliclyAvailableStandards/c065143_ISO_IEC_TR_19075-5_2016.zip]
> [2]
> [https://www.ibm.com/support/knowledgecenter/en/SSEPGG_11.1.0/com.ibm.db2.luw.sql.ref.doc/doc/r0070413.html]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (CALCITE-3093) Remove JDBC connection calls from PlannerImpl
[
https://issues.apache.org/jira/browse/CALCITE-3093?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hongze Zhang resolved CALCITE-3093.
---
Resolution: Fixed
Fix Version/s: 1.20.0
Fixed in
[037250b99d6db8a605b64780a3643f784d07d308|https://github.com/apache/calcite/commit/037250b99d6db8a605b64780a3643f784d07d308].
> Remove JDBC connection calls from PlannerImpl
> -
>
> Key: CALCITE-3093
> URL: https://issues.apache.org/jira/browse/CALCITE-3093
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: Hongze Zhang
>Assignee: Hongze Zhang
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.20.0
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Currently the class {{PlannerImpl}} creates JDBC connections[1] internally to
> instantiate {{RelOptPlanner}}. For improving the design I suggest to reverse
> the call chain, for example, we can make JDBC API call PlannerImpl to create
> {{RelOptPlanner}}, {{SqlValidator}}, {{SqlToRelConverter}} instances, etc.
> This JIRA topic is the first step of the improvement - we should decouple the
> use of JDBC API from PlannerImpl. Planner API is designed to be a reusable
> toolkit and we should make it work individually without the help of JDBC API.
> [1]
> https://github.com/apache/calcite/blob/4e1b68e3c0b2a90832cc790c6166cebb14ae2970/core/src/main/java/org/apache/calcite/prepare/PlannerImpl.java#L143-L151
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (CALCITE-3095) Add several system properties to control enabling/disabling of rules and traits
[ https://issues.apache.org/jira/browse/CALCITE-3095?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hongze Zhang resolved CALCITE-3095. --- Resolution: Fixed Assignee: Hongze Zhang Fixed in [5650beb9e81a5706d614140b43060084b955ce29|https://github.com/apache/calcite/commit/5650beb9e81a5706d614140b43060084b955ce29]. Thanks for your review, [~julianhyde]! > Add several system properties to control enabling/disabling of rules and > traits > --- > > Key: CALCITE-3095 > URL: https://issues.apache.org/jira/browse/CALCITE-3095 > Project: Calcite > Issue Type: Improvement >Reporter: Hongze Zhang >Assignee: Hongze Zhang >Priority: Major > Labels: pull-request-available > Fix For: 1.20.0 > > Time Spent: 20m > Remaining Estimate: 0h > > This is to make following constant flags configurable from Calcite system > properties: > * CalcitePrepareImpl.ENABLE_COLLATION_TRAIT > * CalcitePrepareImpl.ENABLE_ENUMERABLE > * CalcitePrepareImpl.ENABLE_STREAM -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CALCITE-3093) Remove JDBC connection calls from PlannerImpl
[
https://issues.apache.org/jira/browse/CALCITE-3093?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hongze Zhang updated CALCITE-3093:
--
Labels: (was: pull-request-available)
> Remove JDBC connection calls from PlannerImpl
> -
>
> Key: CALCITE-3093
> URL: https://issues.apache.org/jira/browse/CALCITE-3093
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: Hongze Zhang
>Assignee: Hongze Zhang
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently the class {{PlannerImpl}} creates JDBC connections[1] internally to
> instantiate {{RelOptPlanner}}. For improving the design I suggest to reverse
> the call chain, for example, we can make JDBC API call PlannerImpl to create
> {{RelOptPlanner}}, {{SqlValidator}}, {{SqlToRelConverter}} instances, etc.
> This JIRA topic is the first step of the improvement - we should decouple the
> use of JDBC API from PlannerImpl. Planner API is designed to be a reusable
> toolkit and we should make it work individually without the help of JDBC API.
> [1]
> https://github.com/apache/calcite/blob/4e1b68e3c0b2a90832cc790c6166cebb14ae2970/core/src/main/java/org/apache/calcite/prepare/PlannerImpl.java#L143-L151
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CALCITE-3095) Add several system properties to control enabling/disabling of rules and traits
[ https://issues.apache.org/jira/browse/CALCITE-3095?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hongze Zhang updated CALCITE-3095: -- Summary: Add several system properties to control enabling/disabling of rules and traits (was: Add several system properties to control rules and traits) > Add several system properties to control enabling/disabling of rules and > traits > --- > > Key: CALCITE-3095 > URL: https://issues.apache.org/jira/browse/CALCITE-3095 > Project: Calcite > Issue Type: Improvement >Reporter: Hongze Zhang >Priority: Major > Labels: pull-request-available > > This is to make following constant flags configurable from Calcite system > properties: > * CalcitePrepareImpl.ENABLE_COLLATION_TRAIT > * CalcitePrepareImpl.ENABLE_ENUMERABLE > * CalcitePrepareImpl.ENABLE_STREAM -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (CALCITE-3095) Add several system properties to control rules and traits
[
https://issues.apache.org/jira/browse/CALCITE-3095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16849425#comment-16849425
]
Hongze Zhang edited comment on CALCITE-3095 at 5/28/19 7:38 AM:
Changes addressing comments in CALCITE-3093:
* Fix the typos of "calite";
* Mark several public APIs as {{@Experimental}}.
was (Author: zhztheplayer):
Changes addressing comments in CALCITE-3093:
* fix the typos of "calite";
* mark several public APIs as {{@Experimental}}.
> Add several system properties to control rules and traits
> -
>
> Key: CALCITE-3095
> URL: https://issues.apache.org/jira/browse/CALCITE-3095
> Project: Calcite
> Issue Type: Improvement
>Reporter: Hongze Zhang
>Priority: Major
> Labels: pull-request-available
>
> This is to make following constant flags configurable from Calcite system
> properties:
> * CalcitePrepareImpl.ENABLE_COLLATION_TRAIT
> * CalcitePrepareImpl.ENABLE_ENUMERABLE
> * CalcitePrepareImpl.ENABLE_STREAM
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-3095) Add several system properties to control rules and traits
[
https://issues.apache.org/jira/browse/CALCITE-3095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16849425#comment-16849425
]
Hongze Zhang commented on CALCITE-3095:
---
Changes addressing comments in CALCITE-3093:
* fix the typos of "calite";
* mark several public APIs as {{@Experimental}}.
> Add several system properties to control rules and traits
> -
>
> Key: CALCITE-3095
> URL: https://issues.apache.org/jira/browse/CALCITE-3095
> Project: Calcite
> Issue Type: Improvement
>Reporter: Hongze Zhang
>Priority: Major
>
> This is to make following constant flags configurable from Calcite system
> properties:
> * CalcitePrepareImpl.ENABLE_COLLATION_TRAIT
> * CalcitePrepareImpl.ENABLE_ENUMERABLE
> * CalcitePrepareImpl.ENABLE_STREAM
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CALCITE-3095) Add several system properties to control rules and traits
[ https://issues.apache.org/jira/browse/CALCITE-3095?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hongze Zhang updated CALCITE-3095: -- Labels: pull-request-available (was: ) > Add several system properties to control rules and traits > - > > Key: CALCITE-3095 > URL: https://issues.apache.org/jira/browse/CALCITE-3095 > Project: Calcite > Issue Type: Improvement >Reporter: Hongze Zhang >Priority: Major > Labels: pull-request-available > > This is to make following constant flags configurable from Calcite system > properties: > * CalcitePrepareImpl.ENABLE_COLLATION_TRAIT > * CalcitePrepareImpl.ENABLE_ENUMERABLE > * CalcitePrepareImpl.ENABLE_STREAM -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-3093) Remove JDBC connection calls from PlannerImpl
[
https://issues.apache.org/jira/browse/CALCITE-3093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16849414#comment-16849414
]
Hongze Zhang commented on CALCITE-3093:
---
Opened CALCITE-3095 for the system property changes.
> Remove JDBC connection calls from PlannerImpl
> -
>
> Key: CALCITE-3093
> URL: https://issues.apache.org/jira/browse/CALCITE-3093
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: Hongze Zhang
>Assignee: Hongze Zhang
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently the class {{PlannerImpl}} creates JDBC connections[1] internally to
> instantiate {{RelOptPlanner}}. For improving the design I suggest to reverse
> the call chain, for example, we can make JDBC API call PlannerImpl to create
> {{RelOptPlanner}}, {{SqlValidator}}, {{SqlToRelConverter}} instances, etc.
> This JIRA topic is the first step of the improvement - we should decouple the
> use of JDBC API from PlannerImpl. Planner API is designed to be a reusable
> toolkit and we should make it work individually without the help of JDBC API.
> [1]
> https://github.com/apache/calcite/blob/4e1b68e3c0b2a90832cc790c6166cebb14ae2970/core/src/main/java/org/apache/calcite/prepare/PlannerImpl.java#L143-L151
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (CALCITE-3095) Add several system properties to control rules and traits
Hongze Zhang created CALCITE-3095: - Summary: Add several system properties to control rules and traits Key: CALCITE-3095 URL: https://issues.apache.org/jira/browse/CALCITE-3095 Project: Calcite Issue Type: Improvement Reporter: Hongze Zhang This is to make following constant flags configurable from Calcite system properties: * CalcitePrepareImpl.ENABLE_COLLATION_TRAIT * CalcitePrepareImpl.ENABLE_ENUMERABLE * CalcitePrepareImpl.ENABLE_STREAM -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-3093) Remove JDBC connection calls from PlannerImpl
[
https://issues.apache.org/jira/browse/CALCITE-3093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16849324#comment-16849324
]
Hongze Zhang commented on CALCITE-3093:
---
Thanks for the thoughtful ideas, [~julianhyde]. (and sorry for the typo :))
To address your suggestion I'll continue to separate the issue to this one and
another - for adding system properties and fixing PlannerImpl respectively. I
see you suggested to have two commits, I suppose we need independent JIRA
tickets for each, so correct me if I am wrong.
Also I agree that the JDBC connections to Calcite are lightweight. To be honest
I can't tell immediately how we can gain from such changes to PlannerImpl. But
from my perspective it makes the call chain to Calcite internal clearer than
before. And let's consider a bit further - do we have a chance to create a
individual maven module for Calcite JDBC driver (maybe named as
calcite-jdbc-driver or something, to distinguish with the Calcite JDBC
adapter)? Say, if users want to simply use Calcite to query their own data
source, they can import both calcite-jdbc-driver and calcite-core in his code.
If only the Planner API is needed, then the importing of calcite-jdbc-driver
can be eliminated. Just a thought.
> Remove JDBC connection calls from PlannerImpl
> -
>
> Key: CALCITE-3093
> URL: https://issues.apache.org/jira/browse/CALCITE-3093
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: Hongze Zhang
>Assignee: Hongze Zhang
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently the class {{PlannerImpl}} creates JDBC connections[1] internally to
> instantiate {{RelOptPlanner}}. For improving the design I suggest to reverse
> the call chain, for example, we can make JDBC API call PlannerImpl to create
> {{RelOptPlanner}}, {{SqlValidator}}, {{SqlToRelConverter}} instances, etc.
> This JIRA topic is the first step of the improvement - we should decouple the
> use of JDBC API from PlannerImpl. Planner API is designed to be a reusable
> toolkit and we should make it work individually without the help of JDBC API.
> [1]
> https://github.com/apache/calcite/blob/4e1b68e3c0b2a90832cc790c6166cebb14ae2970/core/src/main/java/org/apache/calcite/prepare/PlannerImpl.java#L143-L151
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CALCITE-3093) Remove JDBC connection calls from PlannerImpl
[
https://issues.apache.org/jira/browse/CALCITE-3093?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hongze Zhang updated CALCITE-3093:
--
Summary: Remove JDBC connection calls from PlannerImpl (was: Decouple JDBC
connection calls from PlannerImpl)
> Remove JDBC connection calls from PlannerImpl
> -
>
> Key: CALCITE-3093
> URL: https://issues.apache.org/jira/browse/CALCITE-3093
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: Hongze Zhang
>Assignee: Hongze Zhang
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently the class {{PlannerImpl}} creates JDBC connections[1] internally to
> instantiate {{RelOptPlanner}}. For improving the design I suggest to reverse
> the call chain, for example, we can make JDBC API call PlannerImpl to create
> {{RelOptPlanner}}, {{SqlValidator}}, {{SqlToRelConverter}} instances, etc.
> This JIRA topic is the first step of the improvement - we should decouple the
> use of JDBC API from PlannerImpl. Planner API is designed to be a reusable
> toolkit and we should make it work individually without the help of JDBC API.
> [1]
> https://github.com/apache/calcite/blob/4e1b68e3c0b2a90832cc790c6166cebb14ae2970/core/src/main/java/org/apache/calcite/prepare/PlannerImpl.java#L143-L151
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2866) Allow passing factory of SqlValidator/SqlToRelConverter/CatalogReader into FrameworkConfig
[ https://issues.apache.org/jira/browse/CALCITE-2866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16848760#comment-16848760 ] Hongze Zhang commented on CALCITE-2866: --- Since the PR is now a mix of different improvements, I've filed a separated JIRA issue CALCITE-3093 for the part of decoupling of planner API and JDBC API. > Allow passing factory of SqlValidator/SqlToRelConverter/CatalogReader into > FrameworkConfig > --- > > Key: CALCITE-2866 > URL: https://issues.apache.org/jira/browse/CALCITE-2866 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Hongze Zhang >Assignee: Hongze Zhang >Priority: Major > Labels: pull-request-available, usability > Time Spent: 10m > Remaining Estimate: 0h > > It seems that the customization of SqlValidator / SqlToRelConverter / > CatalogReader in downstream projects is normal. > E.g. Following are some examples (not all) of extended SqlValidator / > SqlToRelConverter / CatalogReader from other projects that are using Calcite > as query planner : > # DrillValidator > > [https://github.com/apache/drill/blob/4627973bde9847a4eb2672c44941136c167326a1/exec/java-exec/src/main/java/org/apache/drill/exec/planner/sql/SqlConverter.java#L249] > # FlinkCalciteSqlValidator > > [https://github.com/apache/flink/blob/master/flink-table/flink-table-planner/src/main/scala/org/apache/flink/table/calcite/FlinkCalciteSqlValidator.scala#L31] > # DremioSqlToRelConverter > > [https://github.com/dremio/dremio-oss/blob/master/sabot/kernel/src/main/java/com/dremio/exec/planner/sql/DremioSqlToRelConverter.java#L40] > # (Dremio) SqlValidatorImpl > > [https://github.com/dremio/dremio-oss/blob/master/sabot/kernel/src/main/java/com/dremio/exec/planner/sql/SqlValidatorImpl.java#L32] > # DremioCatalogReader > > [https://github.com/dremio/dremio-oss/blob/master/sabot/kernel/src/main/java/com/dremio/exec/catalog/DremioCatalogReader.java#L71] > The class tools/Planner.java[1] is a good customization tool for Calcite > user. However currently there are no way to use Frameworks.getPlanner() > directly if the classes need to be customized[2][3]. > > [1] > [https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/tools/Planner.java] > [2] > [https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/prepare/PlannerImpl.java#L232] > [3] > [https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/prepare/PlannerImpl.java#L184] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CALCITE-3093) Decouple JDBC connection calls from PlannerImpl
Hongze Zhang created CALCITE-3093:
-
Summary: Decouple JDBC connection calls from PlannerImpl
Key: CALCITE-3093
URL: https://issues.apache.org/jira/browse/CALCITE-3093
Project: Calcite
Issue Type: Improvement
Components: core
Reporter: Hongze Zhang
Assignee: Hongze Zhang
Currently the class {{PlannerImpl}} creates JDBC connections[1] internally to
instantiate {{RelOptPlanner}}. For improving the design I suggest to reverse
the call chain, for example, we can make JDBC API call PlannerImpl to create
{{RelOptPlanner}}, {{SqlValidator}}, {{SqlToRelConverter}} instances, etc.
This JIRA topic is the first step of the improvement - we should decouple the
use of JDBC API from PlannerImpl. Planner API is designed to be a reusable
toolkit and we should make it work individually without the help of JDBC API.
[1]
https://github.com/apache/calcite/blob/4e1b68e3c0b2a90832cc790c6166cebb14ae2970/core/src/main/java/org/apache/calcite/prepare/PlannerImpl.java#L143-L151
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (CALCITE-35) Support parenthesized sub-clause in JOIN
[ https://issues.apache.org/jira/browse/CALCITE-35?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16847202#comment-16847202 ] Hongze Zhang edited comment on CALCITE-35 at 5/24/19 3:18 AM: -- Just my 2 cents - I would prefer coming up with a better solution, then put the changes to core parser, not only for babel, because the syntax is defined by SQL standard. From this perspective, porting current PR to babel is more like a workaround. Anyway, I like the idea adding some defensive test cases first, thanks for that. was (Author: zhztheplayer): Just my 2 cents - I would prefer coming up with a better solution, then put the changes to core parser, not only for babel, because the syntax is defined by SQL standard. In the sense porting current PR to babel is more like a workaround. Anyway, I like the idea adding some defensive test cases first, thanks for that. > Support parenthesized sub-clause in JOIN > > > Key: CALCITE-35 > URL: https://issues.apache.org/jira/browse/CALCITE-35 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.19.0 >Reporter: GitHub Import >Priority: Major > Labels: github-import, pull-request-available > Time Spent: 1h 10m > Remaining Estimate: 0h > > SQL-92 allows joins to be grouped into trees using parentheses. For example, > select * from a join (b join c on b.x = c.x) on a.y = c.y > Optiq should support this. Currently this gives > "org.eigenbase.util.EigenbaseException: Non-query expression encountered in > illegal context". > Imported from GitHub > Url: https://github.com/julianhyde/optiq/issues/35 > Created by: [julianhyde|https://github.com/julianhyde] > Labels: > Created at: Fri Apr 19 02:46:01 CEST 2013 > State: open -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-35) Support parenthesized sub-clause in JOIN
[ https://issues.apache.org/jira/browse/CALCITE-35?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16847202#comment-16847202 ] Hongze Zhang commented on CALCITE-35: - Just my 2 cents - I would prefer coming up with a better solution, then put the changes to core parser, not only for babel, because the syntax is defined by SQL standard. In the sense porting current PR to babel is more like a workaround. Anyway, I like the idea adding some defensive test cases first, thanks for that. > Support parenthesized sub-clause in JOIN > > > Key: CALCITE-35 > URL: https://issues.apache.org/jira/browse/CALCITE-35 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.19.0 >Reporter: GitHub Import >Priority: Major > Labels: github-import, pull-request-available > Time Spent: 1h 10m > Remaining Estimate: 0h > > SQL-92 allows joins to be grouped into trees using parentheses. For example, > select * from a join (b join c on b.x = c.x) on a.y = c.y > Optiq should support this. Currently this gives > "org.eigenbase.util.EigenbaseException: Non-query expression encountered in > illegal context". > Imported from GitHub > Url: https://github.com/julianhyde/optiq/issues/35 > Created by: [julianhyde|https://github.com/julianhyde] > Labels: > Created at: Fri Apr 19 02:46:01 CEST 2013 > State: open -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (CALCITE-2985) Implement JSON_STORAGE_SIZE function
[
https://issues.apache.org/jira/browse/CALCITE-2985?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hongze Zhang resolved CALCITE-2985.
---
Resolution: Fixed
Fix Version/s: 1.20.0
Fixed in
[b42029fd46958ddf4d62a29182a2dbee66c1adef|https://github.com/apache/calcite/commit/b42029fd46958ddf4d62a29182a2dbee66c1adef].
Thanks, [~x1q1j1]!
> Implement JSON_STORAGE_SIZE function
>
>
> Key: CALCITE-2985
> URL: https://issues.apache.org/jira/browse/CALCITE-2985
> Project: Calcite
> Issue Type: Sub-task
>Reporter: Forward Xu
>Assignee: Forward Xu
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.20.0
>
> Time Spent: 2h 40m
> Remaining Estimate: 0h
>
> JSON_STORAGE_SIZE(json_val)
> This function returns the number of bytes used to store the binary
> representation of a JSON document. When the argument is a JSON column, this
> is the space used to store the JSON document. json_val must be a valid JSON
> document or a string which can be parsed as one. In the case where it is
> string, the function returns the amount of storage space in the JSON binary
> representation that is created by parsing the string as JSON and converting
> it to binary. It returns NULL if the argument is NULL.
> An error results when json_val is not NULL, and is not—or cannot be
> successfully parsed as—a JSON document.
> To illustrate this function's behavior when used with a JSON column as its
> argument, we create a table named jtable containing a JSON column jcol,
> insert a JSON value into the table, then obtain the storage space used by
> this column with JSON_STORAGE_SIZE(), as shown here:
> {code:java}
> SELECT
> JSON_STORAGE_SIZE('[100, "sakila", [1, 3, 5], 425.05]') AS A,
> JSON_STORAGE_SIZE('{"a": 1000, "b": "a", "c": "[1, 3, 5, 7]"}') AS B,
> JSON_STORAGE_SIZE('{"a": 1000, "b": "wxyz", "c": "[1, 3, 5, 7]"}') AS C,
> JSON_STORAGE_SIZE('[100, "json", [[10, 20, 30], 3, 5], 425.05]') AS D;
> {code}
> | A | B | C | D |
> | 29 | 37 | 40 | 36 |
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2985) Implement JSON_STORAGE_SIZE function
[
https://issues.apache.org/jira/browse/CALCITE-2985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16846561#comment-16846561
]
Hongze Zhang commented on CALCITE-2985:
---
The pending commit is here:
https://github.com/zhztheplayer/calcite/commit/b42029fd46958ddf4d62a29182a2dbee66c1adef.
Minor changes:
* Add JsonFunctions#jsonStorageSize and related test cases to support JSON
value expression as input;
* Optimize return type inference;
* Improve documentation a bit;
* Add test cases against null input;
* Remove incorrect changes to keyword list;
* Code style issues (indents, wrapping).
Will commit after CI get passed.
> Implement JSON_STORAGE_SIZE function
>
>
> Key: CALCITE-2985
> URL: https://issues.apache.org/jira/browse/CALCITE-2985
> Project: Calcite
> Issue Type: Sub-task
>Reporter: Forward Xu
>Assignee: Forward Xu
>Priority: Major
> Labels: pull-request-available
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> JSON_STORAGE_SIZE(json_val)
> This function returns the number of bytes used to store the binary
> representation of a JSON document. When the argument is a JSON column, this
> is the space used to store the JSON document. json_val must be a valid JSON
> document or a string which can be parsed as one. In the case where it is
> string, the function returns the amount of storage space in the JSON binary
> representation that is created by parsing the string as JSON and converting
> it to binary. It returns NULL if the argument is NULL.
> An error results when json_val is not NULL, and is not—or cannot be
> successfully parsed as—a JSON document.
> To illustrate this function's behavior when used with a JSON column as its
> argument, we create a table named jtable containing a JSON column jcol,
> insert a JSON value into the table, then obtain the storage space used by
> this column with JSON_STORAGE_SIZE(), as shown here:
> {code:java}
> SELECT
> JSON_STORAGE_SIZE('[100, "sakila", [1, 3, 5], 425.05]') AS A,
> JSON_STORAGE_SIZE('{"a": 1000, "b": "a", "c": "[1, 3, 5, 7]"}') AS B,
> JSON_STORAGE_SIZE('{"a": 1000, "b": "wxyz", "c": "[1, 3, 5, 7]"}') AS C,
> JSON_STORAGE_SIZE('[100, "json", [[10, 20, 30], 3, 5], 425.05]') AS D;
> {code}
> | A | B | C | D |
> | 29 | 37 | 40 | 36 |
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2985) Implement JSON_STORAGE_SIZE function
[
https://issues.apache.org/jira/browse/CALCITE-2985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16846508#comment-16846508
]
Hongze Zhang commented on CALCITE-2985:
---
[~x1q1j1] - I see you updated the PR, thanks for that. However there are still
several minor issues in code so that I'll help to make some improvement on top
of your work before merging if you don't mind.
> Implement JSON_STORAGE_SIZE function
>
>
> Key: CALCITE-2985
> URL: https://issues.apache.org/jira/browse/CALCITE-2985
> Project: Calcite
> Issue Type: Sub-task
>Reporter: Forward Xu
>Assignee: Forward Xu
>Priority: Major
> Labels: pull-request-available
> Time Spent: 2h 20m
> Remaining Estimate: 0h
>
> JSON_STORAGE_SIZE(json_val)
> This function returns the number of bytes used to store the binary
> representation of a JSON document. When the argument is a JSON column, this
> is the space used to store the JSON document. json_val must be a valid JSON
> document or a string which can be parsed as one. In the case where it is
> string, the function returns the amount of storage space in the JSON binary
> representation that is created by parsing the string as JSON and converting
> it to binary. It returns NULL if the argument is NULL.
> An error results when json_val is not NULL, and is not—or cannot be
> successfully parsed as—a JSON document.
> To illustrate this function's behavior when used with a JSON column as its
> argument, we create a table named jtable containing a JSON column jcol,
> insert a JSON value into the table, then obtain the storage space used by
> this column with JSON_STORAGE_SIZE(), as shown here:
> {code:java}
> SELECT
> JSON_STORAGE_SIZE('[100, "sakila", [1, 3, 5], 425.05]') AS A,
> JSON_STORAGE_SIZE('{"a": 1000, "b": "a", "c": "[1, 3, 5, 7]"}') AS B,
> JSON_STORAGE_SIZE('{"a": 1000, "b": "wxyz", "c": "[1, 3, 5, 7]"}') AS C,
> JSON_STORAGE_SIZE('[100, "json", [[10, 20, 30], 3, 5], 425.05]') AS D;
> {code}
> | A | B | C | D |
> | 29 | 37 | 40 | 36 |
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-3065) RexLiteral#getValueAs should consider primitive type
[
https://issues.apache.org/jira/browse/CALCITE-3065?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16845749#comment-16845749
]
Hongze Zhang commented on CALCITE-3065:
---
{quote}And leave my scenario aside, shouldn't "literal.getValueAs" process both
"int" and "Integer"? At least in Java, int and Integer are not so different in
most case.
{quote}
[~Aron.tao] - Integer is nullable, where int is not. And nullability makes
sense in database internal. The operation of transformation between primitive
and boxed types should be always reasonable in Calcite.
And the method {{Class#cast(Object obj)}} behaves quite differently with normal
casting. Personally I don't suggest to call this method on primitive values for
any reason.
If you really want to make some improvements I think it is usual to somehow add
a bunch of methods like "getInt()", "getLong()", etc. But I am not sure if such
methods suit your use case.
> RexLiteral#getValueAs should consider primitive type
>
>
> Key: CALCITE-3065
> URL: https://issues.apache.org/jira/browse/CALCITE-3065
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: Jiatao Tao
>Priority: Major
> Labels: pull-request-available
> Attachments: image-2019-05-13-12-04-36-365.png,
> image-2019-05-17-08-23-52-735.png
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> !image-2019-05-13-12-04-36-365.png!
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2593) Sometimes fails to plan when a RelNode transform multiple collations to single collation
[
https://issues.apache.org/jira/browse/CALCITE-2593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16845446#comment-16845446
]
Hongze Zhang commented on CALCITE-2593:
---
{quote}Since the problem arises from some empty subsets I was wondering if it
is also due to the fact that AbstractConverters are disabled for the
EnumerableConvention.{quote}
Agreed. I suppose that the method {{RelCollationTraitDef#getDefault}}[1] dared
to return empty collation because we are under the assumption that abstract
converters work as expected, but apparently it doesn't. I didn't try enabling
the converters because I saw it is reported that the converters are related to
some sort of performance issue (CALCITE-2970), but maybe I should try it by my
own anyway.
But as we saw, another root cause is the simplification of composite trait. I
see Vladimir has proposed PR#989[2] and we haven't made progress on it yet.
P.S. I've closed PR#984[3]. Because I was no longer satisfied with the approach
after some time.
[1]
https://github.com/apache/calcite/blob/61b858db13c2e1997e92172a09f38c639ffdceee/core/src/main/java/org/apache/calcite/rel/RelCollationTraitDef.java#L58-L60
[2] https://github.com/apache/calcite/pull/989
[3] https://github.com/apache/calcite/pull/984
> Sometimes fails to plan when a RelNode transform multiple collations to
> single collation
>
>
> Key: CALCITE-2593
> URL: https://issues.apache.org/jira/browse/CALCITE-2593
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Hongze Zhang
>Priority: Major
> Labels: pull-request-available
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Sample SQL:
> {code:java}
> select sum(X + 1) filter (where Y) as "SET" from (values (1, TRUE), (2,
> TRUE)) AS t(X, Y) limit 10{code}
> Error log:
> {code:java}
> java.lang.RuntimeException: exception while executing [select sum(X + 1)
> filter (where Y) as "SET" from (values (1, TRUE), (2, TRUE)) AS t(X, Y) limit
> 10] at
> org.apache.calcite.test.CalciteAssert$AssertQuery.returns(CalciteAssert.java:1366)
> at
> org.apache.calcite.test.CalciteAssert$AssertQuery.returns(CalciteAssert.java:1339)
> at
> org.apache.calcite.test.CalciteAssert$AssertQuery.returns(CalciteAssert.java:1302)
> at
> org.apache.calcite.test.JdbcTest.testWithinGroupClause5(JdbcTest.java:6736)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498) at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325) at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) at
> org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) at
> org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) at
> org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) at
> org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) at
> org.junit.runners.ParentRunner.run(ParentRunner.java:363) at
> org.junit.runner.JUnitCore.run(JUnitCore.java:137) at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
> at
> com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:47)
> at
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
> at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)
> Caused by: java.lang.RuntimeException: With materializationsEnabled=false,
> limit=0 at
> org.apache.calcite.test.CalciteAssert.assertQuery(CalciteAssert.java:573) at
> org.apache.calcite.test.CalciteAssert$AssertQuery.returns(CalciteAssert.java:1362)
> ... 25 more Caused by: java.sql.SQLException: Error while executing SQL
> "select sum(X + 1) filter (where Y) as "SET" from (values (1, TRUE), (2,
> TRUE)) AS t(X, Y) limit 10": Node [rel#22:Subset#3.ENUMERABLE.[]] could not
> be implemented; planner state: Root: rel#22:Subset#3.ENUMERABLE.[] Original
> rel: LogicalSort(subset=[rel#22:Subset#3.ENUMERABLE.[]], fetch=[10]):
> rowcount =
[jira] [Comment Edited] (CALCITE-2921) nullif(null,y) throws exception in verification
[
https://issues.apache.org/jira/browse/CALCITE-2921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16844657#comment-16844657
]
Hongze Zhang edited comment on CALCITE-2921 at 5/21/19 9:09 AM:
Is functionality of the new added method {{SqlTypeTransforms#nullToDefault}}
overlapping {{SqlOperandTypeInference}}?
was (Author: zhztheplayer):
Is functionality of the new added method {{SqlTypeTransforms#nullToDefault}}
overlaps {{SqlOperandTypeInference}}?
> nullif(null,y) throws exception in verification
>
>
> Key: CALCITE-2921
> URL: https://issues.apache.org/jira/browse/CALCITE-2921
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.18.0
>Reporter: pengzhiwei
>Assignee: pengzhiwei
>Priority: Critical
> Labels: pull-request-available
> Fix For: 1.20.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently calcite will translate "nullif(x,y)" to a case-when expression,just
> like "case when x = y then null else x".So when "x" is null literal,a
> exception throws out as follow:
> {code:java}
> ELSE clause or at least one THEN clause must be non-NULL
> {code}
> I have test in mysql,"nullif(null,y) works well.So I think we should allow
> this usage of "nullif".
> There are two ways to fix this issue:
> 1) Skip the check for "foundNotNull" in SqlCaseOperator#checkOperandTypes:
>
> {code:java}
> if (!foundNotNull) {
> // according to the sql standard we can not have all of the THEN
> // statements and the ELSE returning null
> if (throwOnFailure) {
> throw callBinding.newError(RESOURCE.mustNotNullInElse());
> }
> return false;
> }{code}
> However, as the comment says, we cannot have all of the THEN and ELSE
> returning null.
> 2) Disable the translation from nullif to case-when and keep "nullif" as it
> is.
> Any suggestion is welcomed,Thanks!
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2921) nullif(null,y) throws exception in verification
[
https://issues.apache.org/jira/browse/CALCITE-2921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16844657#comment-16844657
]
Hongze Zhang commented on CALCITE-2921:
---
Is functionality of the new added method {{SqlTypeTransforms#nullToDefault}}
overlaps {{SqlOperandTypeInference}}?
> nullif(null,y) throws exception in verification
>
>
> Key: CALCITE-2921
> URL: https://issues.apache.org/jira/browse/CALCITE-2921
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.18.0
>Reporter: pengzhiwei
>Assignee: pengzhiwei
>Priority: Critical
> Labels: pull-request-available
> Fix For: 1.20.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently calcite will translate "nullif(x,y)" to a case-when expression,just
> like "case when x = y then null else x".So when "x" is null literal,a
> exception throws out as follow:
> {code:java}
> ELSE clause or at least one THEN clause must be non-NULL
> {code}
> I have test in mysql,"nullif(null,y) works well.So I think we should allow
> this usage of "nullif".
> There are two ways to fix this issue:
> 1) Skip the check for "foundNotNull" in SqlCaseOperator#checkOperandTypes:
>
> {code:java}
> if (!foundNotNull) {
> // according to the sql standard we can not have all of the THEN
> // statements and the ELSE returning null
> if (throwOnFailure) {
> throw callBinding.newError(RESOURCE.mustNotNullInElse());
> }
> return false;
> }{code}
> However, as the comment says, we cannot have all of the THEN and ELSE
> returning null.
> 2) Disable the translation from nullif to case-when and keep "nullif" as it
> is.
> Any suggestion is welcomed,Thanks!
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (CALCITE-3067) Splunk adapter cannot parse right session keys from Splunk 7.2
[ https://issues.apache.org/jira/browse/CALCITE-3067?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hongze Zhang resolved CALCITE-3067. --- Resolution: Fixed Fixed in [2765791e60c46e0d66a3c510a5c91d16fe757720|https://github.com/apache/calcite/commit/2765791e60c46e0d66a3c510a5c91d16fe757720]. Thanks for your contribution, [~Shawn732]! > Splunk adapter cannot parse right session keys from Splunk 7.2 > -- > > Key: CALCITE-3067 > URL: https://issues.apache.org/jira/browse/CALCITE-3067 > Project: Calcite > Issue Type: Bug > Components: splunk >Affects Versions: 1.19.0 > Environment: Splunk 7.2 on Mac OS 10.14 > Calcite 1.19 >Reporter: Shawn Chen >Assignee: Shawn Chen >Priority: Major > Labels: pull-request-available > Fix For: next > > Original Estimate: 2h > Time Spent: 3h > Remaining Estimate: 0h > > *SplunkConnectionImpl.java* successfully builds a connection to Splunk 7.2, > but it cannot parse the correct session key due to the outdated regular > expression in this class, therefore it gets HTTP 401 response after sending > further search commands to Splunk. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CALCITE-3067) Splunk adapter cannot parse right session keys from Splunk 7.2
[ https://issues.apache.org/jira/browse/CALCITE-3067?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hongze Zhang updated CALCITE-3067: -- Fix Version/s: (was: next) 1.20.0 > Splunk adapter cannot parse right session keys from Splunk 7.2 > -- > > Key: CALCITE-3067 > URL: https://issues.apache.org/jira/browse/CALCITE-3067 > Project: Calcite > Issue Type: Bug > Components: splunk >Affects Versions: 1.19.0 > Environment: Splunk 7.2 on Mac OS 10.14 > Calcite 1.19 >Reporter: Shawn Chen >Assignee: Shawn Chen >Priority: Major > Labels: pull-request-available > Fix For: 1.20.0 > > Original Estimate: 2h > Time Spent: 3h > Remaining Estimate: 0h > > *SplunkConnectionImpl.java* successfully builds a connection to Splunk 7.2, > but it cannot parse the correct session key due to the outdated regular > expression in this class, therefore it gets HTTP 401 response after sending > further search commands to Splunk. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CALCITE-3067) Splunk adapter cannot parse right session keys from Splunk 7.2
[ https://issues.apache.org/jira/browse/CALCITE-3067?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hongze Zhang updated CALCITE-3067: -- Summary: Splunk adapter cannot parse right session keys from Splunk 7.2 (was: Splunk Calcite adapter cannot parse right session keys from Splunk 7.2) > Splunk adapter cannot parse right session keys from Splunk 7.2 > -- > > Key: CALCITE-3067 > URL: https://issues.apache.org/jira/browse/CALCITE-3067 > Project: Calcite > Issue Type: Bug > Components: splunk >Affects Versions: 1.19.0 > Environment: Splunk 7.2 on Mac OS 10.14 > Calcite 1.19 >Reporter: Shawn Chen >Assignee: Shawn Chen >Priority: Major > Labels: pull-request-available > Fix For: next > > Original Estimate: 2h > Time Spent: 2h 50m > Remaining Estimate: 0h > > *SplunkConnectionImpl.java* successfully builds a connection to Splunk 7.2, > but it cannot parse the correct session key due to the outdated regular > expression in this class, therefore it gets HTTP 401 response after sending > further search commands to Splunk. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-3067) Splunk Calcite adapter cannot parse right session keys from Splunk 7.2
[ https://issues.apache.org/jira/browse/CALCITE-3067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16844452#comment-16844452 ] Hongze Zhang commented on CALCITE-3067: --- Looks good to me now. Note that next time you don't have to file a new PR when you are making changes, you can just modify and re-push Git branch of the existing one. > Splunk Calcite adapter cannot parse right session keys from Splunk 7.2 > -- > > Key: CALCITE-3067 > URL: https://issues.apache.org/jira/browse/CALCITE-3067 > Project: Calcite > Issue Type: Bug > Components: splunk >Affects Versions: 1.19.0 > Environment: Splunk 7.2 on Mac OS 10.14 > Calcite 1.19 >Reporter: Shawn Chen >Assignee: Shawn Chen >Priority: Major > Labels: pull-request-available > Fix For: next > > Original Estimate: 2h > Time Spent: 2h 50m > Remaining Estimate: 0h > > *SplunkConnectionImpl.java* successfully builds a connection to Splunk 7.2, > but it cannot parse the correct session key due to the outdated regular > expression in this class, therefore it gets HTTP 401 response after sending > further search commands to Splunk. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (CALCITE-2593) Sometimes fails to plan when a RelNode transform multiple collations to single collation
[
https://issues.apache.org/jira/browse/CALCITE-2593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16843613#comment-16843613
]
Hongze Zhang edited comment on CALCITE-2593 at 5/20/19 8:17 AM:
Thanks [~zabetak] for looking into this again. I support the idea changing the
requirement of EnumerableSort's input collation to empty, and also, we should
look into cases that are without a sort involved, such as the case in issue
description, which seems not able to be healed by tweaking sort rules only
(correct me if I am wrong :)). I think maybe we'll end up changing something
related to the basic of composite traits.
was (Author: zhztheplayer):
Thanks [~zabetak] for looking into this again. I support the idea enforcing
EnumerableSort's input collation to empty, and also, we should look into cases
that are without a sort involved, such as the case in issue description, which
seems not able to be healed by tweaking sort rules only (correct me if I am
wrong :)). I think maybe we'll end up changing something related to the basic
of composite traits.
> Sometimes fails to plan when a RelNode transform multiple collations to
> single collation
>
>
> Key: CALCITE-2593
> URL: https://issues.apache.org/jira/browse/CALCITE-2593
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Hongze Zhang
>Priority: Major
> Labels: pull-request-available
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Sample SQL:
> {code:java}
> select sum(X + 1) filter (where Y) as "SET" from (values (1, TRUE), (2,
> TRUE)) AS t(X, Y) limit 10{code}
> Error log:
> {code:java}
> java.lang.RuntimeException: exception while executing [select sum(X + 1)
> filter (where Y) as "SET" from (values (1, TRUE), (2, TRUE)) AS t(X, Y) limit
> 10] at
> org.apache.calcite.test.CalciteAssert$AssertQuery.returns(CalciteAssert.java:1366)
> at
> org.apache.calcite.test.CalciteAssert$AssertQuery.returns(CalciteAssert.java:1339)
> at
> org.apache.calcite.test.CalciteAssert$AssertQuery.returns(CalciteAssert.java:1302)
> at
> org.apache.calcite.test.JdbcTest.testWithinGroupClause5(JdbcTest.java:6736)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498) at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325) at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) at
> org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) at
> org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) at
> org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) at
> org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) at
> org.junit.runners.ParentRunner.run(ParentRunner.java:363) at
> org.junit.runner.JUnitCore.run(JUnitCore.java:137) at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
> at
> com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:47)
> at
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
> at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)
> Caused by: java.lang.RuntimeException: With materializationsEnabled=false,
> limit=0 at
> org.apache.calcite.test.CalciteAssert.assertQuery(CalciteAssert.java:573) at
> org.apache.calcite.test.CalciteAssert$AssertQuery.returns(CalciteAssert.java:1362)
> ... 25 more Caused by: java.sql.SQLException: Error while executing SQL
> "select sum(X + 1) filter (where Y) as "SET" from (values (1, TRUE), (2,
> TRUE)) AS t(X, Y) limit 10": Node [rel#22:Subset#3.ENUMERABLE.[]] could not
> be implemented; planner state: Root: rel#22:Subset#3.ENUMERABLE.[] Original
> rel: LogicalSort(subset=[rel#22:Subset#3.ENUMERABLE.[]], fetch=[10]):
> rowcount = 1.0, cumulative cost = {1.0 rows, 4.0 cpu, 0.0 io}, id = 17
> LogicalAggregate(subset=[rel#16:Subset#2.NONE.[]], group=[{}], SET=[SUM($0)
> FILTER $1]): rowcount = 1.0,
[jira] [Commented] (CALCITE-2593) Sometimes fails to plan when a RelNode transform multiple collations to single collation
[
https://issues.apache.org/jira/browse/CALCITE-2593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16843613#comment-16843613
]
Hongze Zhang commented on CALCITE-2593:
---
Thanks [~zabetak] for looking into this again. I support the idea enforcing
EnumerableSort's input collation to empty, and also, we should look into cases
that are without a sort involved, such as the case in issue description, which
seems not able to be healed by tweaking sort rules only (correct me if I am
wrong :)). I think maybe we'll end up changing something related to the basic
of composite traits.
> Sometimes fails to plan when a RelNode transform multiple collations to
> single collation
>
>
> Key: CALCITE-2593
> URL: https://issues.apache.org/jira/browse/CALCITE-2593
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Hongze Zhang
>Priority: Major
> Labels: pull-request-available
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Sample SQL:
> {code:java}
> select sum(X + 1) filter (where Y) as "SET" from (values (1, TRUE), (2,
> TRUE)) AS t(X, Y) limit 10{code}
> Error log:
> {code:java}
> java.lang.RuntimeException: exception while executing [select sum(X + 1)
> filter (where Y) as "SET" from (values (1, TRUE), (2, TRUE)) AS t(X, Y) limit
> 10] at
> org.apache.calcite.test.CalciteAssert$AssertQuery.returns(CalciteAssert.java:1366)
> at
> org.apache.calcite.test.CalciteAssert$AssertQuery.returns(CalciteAssert.java:1339)
> at
> org.apache.calcite.test.CalciteAssert$AssertQuery.returns(CalciteAssert.java:1302)
> at
> org.apache.calcite.test.JdbcTest.testWithinGroupClause5(JdbcTest.java:6736)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498) at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325) at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) at
> org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) at
> org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) at
> org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) at
> org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) at
> org.junit.runners.ParentRunner.run(ParentRunner.java:363) at
> org.junit.runner.JUnitCore.run(JUnitCore.java:137) at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
> at
> com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:47)
> at
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
> at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)
> Caused by: java.lang.RuntimeException: With materializationsEnabled=false,
> limit=0 at
> org.apache.calcite.test.CalciteAssert.assertQuery(CalciteAssert.java:573) at
> org.apache.calcite.test.CalciteAssert$AssertQuery.returns(CalciteAssert.java:1362)
> ... 25 more Caused by: java.sql.SQLException: Error while executing SQL
> "select sum(X + 1) filter (where Y) as "SET" from (values (1, TRUE), (2,
> TRUE)) AS t(X, Y) limit 10": Node [rel#22:Subset#3.ENUMERABLE.[]] could not
> be implemented; planner state: Root: rel#22:Subset#3.ENUMERABLE.[] Original
> rel: LogicalSort(subset=[rel#22:Subset#3.ENUMERABLE.[]], fetch=[10]):
> rowcount = 1.0, cumulative cost = {1.0 rows, 4.0 cpu, 0.0 io}, id = 17
> LogicalAggregate(subset=[rel#16:Subset#2.NONE.[]], group=[{}], SET=[SUM($0)
> FILTER $1]): rowcount = 1.0, cumulative cost = {1.1375000476837158 rows, 0.0
> cpu, 0.0 io}, id = 15 LogicalProject(subset=[rel#14:Subset#1.NONE.[1]],
> $f0=[+($0, 1)], Y=[$1]): rowcount = 2.0, cumulative cost = {2.0 rows, 4.0
> cpu, 0.0 io}, id = 13 LogicalValues(subset=[rel#12:Subset#0.NONE.[]],
> tuples=[[{ 1, true }, { 2, true }]]): rowcount = 2.0, cumulative cost = {2.0
> rows, 1.0 cpu, 0.0 io}, id = 1 Sets: Set#0, type: RecordType(INTEGER X,
> BOOLEAN Y) rel#12:Subset#0.NONE.[], best=null, importance=0.6561
>
[jira] [Resolved] (CALCITE-3074) Move MySQL's JSON operators to SqlLibraryOperators
[ https://issues.apache.org/jira/browse/CALCITE-3074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hongze Zhang resolved CALCITE-3074. --- Resolution: Fixed Fixed in [ca92ce27ce9f9a40d755a165041d64538a467a10|https://github.com/apache/calcite/commit/ca92ce27ce9f9a40d755a165041d64538a467a10]. Thanks for your review, [~hyuan]! > Move MySQL's JSON operators to SqlLibraryOperators > -- > > Key: CALCITE-3074 > URL: https://issues.apache.org/jira/browse/CALCITE-3074 > 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: 20m > Remaining Estimate: 0h > > This is a follow-up to CALCITE-2846. We should move the instantiating logic > to SqlLibraryOperators and deprecated old ones that are in std operator table. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (CALCITE-3075) Evaluate Travis CI for Windows build
[ https://issues.apache.org/jira/browse/CALCITE-3075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16841867#comment-16841867 ] Hongze Zhang edited comment on CALCITE-3075 at 5/17/19 3:20 AM: Thanks Kevin and Francis! I somehow missed the talk in that thread :), sorry about that. And looks like it is been a time (> 5 months?) after that talk. May be I can help to test the Travis Windows build on my personal branch of Calcite/Avatica first, to see if it is enough to be used in production. By the way, [~krisden] - are there some known issues of the new Windows CI you have found last time? Maybe we can double check if they get fixed/improved at this time. was (Author: zhztheplayer): Thanks Kevin and Francis! I somehow missed the talk in that thread :), sorry about that. And looks like it is been a time (> 5 months?) after that talk. May be I can help to test the Travis Windows build on my personal branch of Calcite/Avatica first, to see if it is enough to be used in production. By the way, [~krisden] - are there some known issues of the new Windows CI you have found last time? Maybe we can double check if they get fixed/improved at the time. > Evaluate Travis CI for Windows build > > > Key: CALCITE-3075 > URL: https://issues.apache.org/jira/browse/CALCITE-3075 > Project: Calcite > Issue Type: Improvement >Reporter: Hongze Zhang >Priority: Major > > Travis.org supports running CI on Windows now: > https://blog.travis-ci.com/2018-10-11-windows-early-release, it is probably > worth to investigate if running Windows CI using Travis would benefit us more > than AppVevor can do. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-3075) Evaluate Travis CI for Windows build
[
https://issues.apache.org/jira/browse/CALCITE-3075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16841871#comment-16841871
]
Hongze Zhang commented on CALCITE-3075:
---
{quote}I kind of have interest on this topic, i will try to find some
references this weekend.{quote}
Thanks for your help, Danny!
> Evaluate Travis CI for Windows build
>
>
> Key: CALCITE-3075
> URL: https://issues.apache.org/jira/browse/CALCITE-3075
> Project: Calcite
> Issue Type: Improvement
>Reporter: Hongze Zhang
>Priority: Major
>
> Travis.org supports running CI on Windows now:
> https://blog.travis-ci.com/2018-10-11-windows-early-release, it is probably
> worth to investigate if running Windows CI using Travis would benefit us more
> than AppVevor can do.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-3075) Evaluate Travis CI for Windows build
[ https://issues.apache.org/jira/browse/CALCITE-3075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16841867#comment-16841867 ] Hongze Zhang commented on CALCITE-3075: --- Thanks Kevin and Francis! I somehow missed the talk in that thread :), sorry about that. And looks like it is been a time (> 5 months?) after that talk. May be I can help to test the Travis Windows build on my personal branch of Calcite/Avatica first, to see if it is enough to be used in production. By the way, [~krisden] - are there some known issues of the new Windows CI you have found last time? Maybe we can double check if they get fixed/improved at the time. > Evaluate Travis CI for Windows build > > > Key: CALCITE-3075 > URL: https://issues.apache.org/jira/browse/CALCITE-3075 > Project: Calcite > Issue Type: Improvement >Reporter: Hongze Zhang >Priority: Major > > Travis.org supports running CI on Windows now: > https://blog.travis-ci.com/2018-10-11-windows-early-release, it is probably > worth to investigate if running Windows CI using Travis would benefit us more > than AppVevor can do. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-3075) Evaluate Travis CI for Windows build
[
https://issues.apache.org/jira/browse/CALCITE-3075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16841473#comment-16841473
]
Hongze Zhang commented on CALCITE-3075:
---
Also, sometimes I slightly feel that AppVeyor build has more chances to get
stuck at {{Queued}} status than Travis when we update PRs. I am not sure if
their build concurrency are different. Does anyone know something about that?
> Evaluate Travis CI for Windows build
>
>
> Key: CALCITE-3075
> URL: https://issues.apache.org/jira/browse/CALCITE-3075
> Project: Calcite
> Issue Type: Improvement
>Reporter: Hongze Zhang
>Priority: Major
>
> Travis.org supports running CI on Windows now:
> https://blog.travis-ci.com/2018-10-11-windows-early-release, it is probably
> worth to investigate if running Windows CI using Travis would benefit us more
> than AppVevor can do.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (CALCITE-3075) Evaluate Travis CI for Windows build
[ https://issues.apache.org/jira/browse/CALCITE-3075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16841454#comment-16841454 ] Hongze Zhang edited comment on CALCITE-3075 at 5/16/19 3:33 PM: One possible disadvantage of AppVeyor might be the performance - Now Calcite's AppVevor CI need ~18 min (seems 15 min for most cases, 20+ min for bad ones) to finish a build, as a comparison Travis CI costs ~13 min. Not sure if for Windows build Travis can still be faster. It would be much appreciated if anyone has experience on Travis+Windows and be willing to share some. was (Author: zhztheplayer): One possible disadvantage of AppVeyor might be the performance - Now Calcite's AppVevor CI need ~18 min to finish a build, as a comparison Travis CI costs ~13 min. Not sure if for Windows build Travis can still be faster. It would be much appreciated if anyone has experience on Travis+Windows and be willing to share some. > Evaluate Travis CI for Windows build > > > Key: CALCITE-3075 > URL: https://issues.apache.org/jira/browse/CALCITE-3075 > Project: Calcite > Issue Type: Improvement >Reporter: Hongze Zhang >Priority: Major > > Travis.org supports running CI on Windows now: > https://blog.travis-ci.com/2018-10-11-windows-early-release, it is probably > worth to investigate if running Windows CI using Travis would benefit us more > than AppVevor can do. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (CALCITE-3075) Evaluate Travis CI for Windows build
[ https://issues.apache.org/jira/browse/CALCITE-3075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16841454#comment-16841454 ] Hongze Zhang edited comment on CALCITE-3075 at 5/16/19 3:28 PM: One possible disadvantage of AppVeyor might be the performance - Now Calcite's AppVevor CI need ~18 min to finish a build, as a comparison Travis CI costs ~13 min. Not sure if for Windows build Travis can still be faster. It would be much appreciated if anyone has experience on Travis+Windows and be willing to share some. was (Author: zhztheplayer): One possible disadvantage of AppVeyor might be the performance - Now Calcite's AppVevor CI need ~20 min to finish a build, as a comparison Travis CI costs ~13 min. Not sure if for Windows build Travis can still be faster. It would be much appreciated if anyone has experience on Travis+Windows and be willing to share some. > Evaluate Travis CI for Windows build > > > Key: CALCITE-3075 > URL: https://issues.apache.org/jira/browse/CALCITE-3075 > Project: Calcite > Issue Type: Improvement >Reporter: Hongze Zhang >Priority: Major > > Travis.org supports running CI on Windows now: > https://blog.travis-ci.com/2018-10-11-windows-early-release, it is probably > worth to investigate if running Windows CI using Travis would benefit us more > than AppVevor can do. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-3075) Evaluate Travis CI for Windows build
[ https://issues.apache.org/jira/browse/CALCITE-3075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16841454#comment-16841454 ] Hongze Zhang commented on CALCITE-3075: --- One possible disadvantage of AppVeyor might be the performance - Now Calcite's AppVevor CI need ~20 min to finish a build, as a comparison Travis CI costs ~13 min. Not sure if for Windows build Travis can still be faster. It would be much appreciated if anyone has experience on Travis+Windows and be willing to share some. > Evaluate Travis CI for Windows build > > > Key: CALCITE-3075 > URL: https://issues.apache.org/jira/browse/CALCITE-3075 > Project: Calcite > Issue Type: Improvement >Reporter: Hongze Zhang >Priority: Major > > Travis.org supports running CI on Windows now: > https://blog.travis-ci.com/2018-10-11-windows-early-release, it is probably > worth to investigate if running Windows CI using Travis would benefit us more > than AppVevor can do. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CALCITE-3075) Evaluate Travis CI for Windows build
Hongze Zhang created CALCITE-3075: - Summary: Evaluate Travis CI for Windows build Key: CALCITE-3075 URL: https://issues.apache.org/jira/browse/CALCITE-3075 Project: Calcite Issue Type: Improvement Reporter: Hongze Zhang Travis.org supports running CI on Windows now: https://blog.travis-ci.com/2018-10-11-windows-early-release, it is probably worth to investigate if running Windows CI using Travis would benefit us more than AppVevor can do. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CALCITE-3074) Move MySQL's JSON operators to SqlLibraryOperators
[ https://issues.apache.org/jira/browse/CALCITE-3074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hongze Zhang updated CALCITE-3074: -- Description: This is a follow-up to CALCITE-2846. We should move the instantiating logic to SqlLibraryOperators and deprecated old ones that are in std operator table. (was: This is a follow-up to CALCITE-2846. We have some JSON operators in the ) > Move MySQL's JSON operators to SqlLibraryOperators > -- > > Key: CALCITE-3074 > URL: https://issues.apache.org/jira/browse/CALCITE-3074 > Project: Calcite > Issue Type: Sub-task >Reporter: Hongze Zhang >Assignee: Hongze Zhang >Priority: Major > Fix For: 1.20.0 > > > This is a follow-up to CALCITE-2846. We should move the instantiating logic > to SqlLibraryOperators and deprecated old ones that are in std operator table. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CALCITE-3074) Move MySQL's JSON operators to SqlLibraryOperators
[ https://issues.apache.org/jira/browse/CALCITE-3074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hongze Zhang updated CALCITE-3074: -- Description: This is a follow-up to CALCITE-2846. We have some JSON operators in the (was: This is a follow-up to CALCITE-2846.) > Move MySQL's JSON operators to SqlLibraryOperators > -- > > Key: CALCITE-3074 > URL: https://issues.apache.org/jira/browse/CALCITE-3074 > Project: Calcite > Issue Type: Sub-task >Reporter: Hongze Zhang >Assignee: Hongze Zhang >Priority: Major > Fix For: 1.20.0 > > > This is a follow-up to CALCITE-2846. We have some JSON operators in the -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CALCITE-3074) Move MySQL's JSON operators to SqlLibraryOperators
Hongze Zhang created CALCITE-3074: - Summary: Move MySQL's JSON operators to SqlLibraryOperators Key: CALCITE-3074 URL: https://issues.apache.org/jira/browse/CALCITE-3074 Project: Calcite Issue Type: Sub-task Reporter: Hongze Zhang Assignee: Hongze Zhang Fix For: 1.20.0 This is a follow-up to CALCITE-2846. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (CALCITE-2975) Implement JSON_REMOVE function
[
https://issues.apache.org/jira/browse/CALCITE-2975?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hongze Zhang resolved CALCITE-2975.
---
Resolution: Fixed
Fix Version/s: 1.20.0
Fixed in [999c41d5ff893a30b2622442a448102c72fc475e
|https://github.com/apache/calcite/commit/999c41d5ff893a30b2622442a448102c72fc475e].
Thanks [~x1q1j1]!
> Implement JSON_REMOVE function
> --
>
> Key: CALCITE-2975
> URL: https://issues.apache.org/jira/browse/CALCITE-2975
> Project: Calcite
> Issue Type: Sub-task
>Reporter: Forward Xu
>Assignee: Forward Xu
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.20.0
>
> Time Spent: 3.5h
> Remaining Estimate: 0h
>
> JSON_REMOVE(json_doc, path[, path] ...)
> Removes data from a JSON document and returns the result. Returns NULL if any
> argument is NULL. An error occurs if the json_doc argument is not a valid
> JSON document or any path argument is not a valid path expression or is $ or
> contains a * or ** wildcard.
> The path arguments are evaluated left to right. The document produced by
> evaluating one path becomes the new value against which the next path is
> evaluated.
> It is not an error if the element to be removed does not exist in the
> document; in that case, the path does not affect the document.
> JSON_REMOVE SQL:
> {code:java}
> SELECT JSON_REMOVE(v, '$[1]') AS c1
> FROM (VALUES ('["a", ["b", "c"], "d"]')) AS t(v);
> {code}
> RESULT:
> ||c1||
> |["a", "d"]|
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CALCITE-2985) Implement JSON_STORAGE_SIZE function
[
https://issues.apache.org/jira/browse/CALCITE-2985?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hongze Zhang updated CALCITE-2985:
--
Summary: Implement JSON_STORAGE_SIZE function (was: Add the
JSON_STORAGE_SIZE function)
> Implement JSON_STORAGE_SIZE function
>
>
> Key: CALCITE-2985
> URL: https://issues.apache.org/jira/browse/CALCITE-2985
> Project: Calcite
> Issue Type: Sub-task
>Reporter: Forward Xu
>Assignee: Forward Xu
>Priority: Major
> Labels: pull-request-available
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> JSON_STORAGE_SIZE(json_val)
> This function returns the number of bytes used to store the binary
> representation of a JSON document. When the argument is a JSON column, this
> is the space used to store the JSON document. json_val must be a valid JSON
> document or a string which can be parsed as one. In the case where it is
> string, the function returns the amount of storage space in the JSON binary
> representation that is created by parsing the string as JSON and converting
> it to binary. It returns NULL if the argument is NULL.
> An error results when json_val is not NULL, and is not—or cannot be
> successfully parsed as—a JSON document.
> To illustrate this function's behavior when used with a JSON column as its
> argument, we create a table named jtable containing a JSON column jcol,
> insert a JSON value into the table, then obtain the storage space used by
> this column with JSON_STORAGE_SIZE(), as shown here:
> {code:java}
> SELECT
> JSON_STORAGE_SIZE('[100, "sakila", [1, 3, 5], 425.05]') AS A,
> JSON_STORAGE_SIZE('{"a": 1000, "b": "a", "c": "[1, 3, 5, 7]"}') AS B,
> JSON_STORAGE_SIZE('{"a": 1000, "b": "wxyz", "c": "[1, 3, 5, 7]"}') AS C,
> JSON_STORAGE_SIZE('[100, "json", [[10, 20, 30], 3, 5], 425.05]') AS D;
> {code}
> | A | B | C | D |
> | 29 | 37 | 40 | 36 |
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CALCITE-2884) Implement JSON_INSERT, JSON_REPLACE, JSON_SET
[
https://issues.apache.org/jira/browse/CALCITE-2884?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hongze Zhang updated CALCITE-2884:
--
Summary: Implement JSON_INSERT, JSON_REPLACE, JSON_SET (was: Add the
JSON_INSERT,JSON_REPLACE,JSON_SET function)
> Implement JSON_INSERT, JSON_REPLACE, JSON_SET
> -
>
> Key: CALCITE-2884
> URL: https://issues.apache.org/jira/browse/CALCITE-2884
> Project: Calcite
> Issue Type: Sub-task
>Reporter: Forward Xu
>Assignee: Forward Xu
>Priority: Major
> Labels: pull-request-available
> Time Spent: 2h 10m
> Remaining Estimate: 0h
>
> {{JSON_INSERT(jsondoc}}, _{{path}}_, _{{val}}_[, path, val] )
> {{JSON_REPLACE(jsondoc}}, _{{path}}_, _{{val}}_[, path, val] )
> {{JSON_SET(jsondoc}}, _{{path}}_, _{{val}}_[, path, val] )
> Inserts data into a JSON document and returns the result. Returns {{NULL}} if
> any argument is {{NULL}}. An error occurs if the _{{json_doc}}_ argument is
> not a valid JSON document or any _{{path}}_ argument is not a valid path
> expression or contains a *or {{**}} wildcard.
> The path-value pairs are evaluated left to right. The document produced by
> evaluating one pair becomes the new value against which the next pair is
> evaluated.
> A path-value pair for an existing path in the document is ignored and does
> not overwrite the existing document value. A path-value pair for a
> nonexisting path in the document adds the value to the document if the path
> identifies one of these types of values:
> * A member not present in an existing object. The member is added to the
> object and associated with the new value.
> * A position past the end of an existing array. The array is extended with
> the new value. If the existing value is not an array, it is autowrapped as an
> array, then extended with the new value.
> Otherwise, a path-value pair for a nonexisting path in the document is
> ignored and has no effect.
> For a comparison of
> [{{JSON_INSERT()}}|https://dev.mysql.com/doc/refman/5.7/en/json-modification-functions.html#function_json-insert],
>
> [{{JSON_REPLACE()}}|https://dev.mysql.com/doc/refman/5.7/en/json-modification-functions.html#function_json-replace],
> and
> [{{JSON_SET()}}|https://dev.mysql.com/doc/refman/5.7/en/json-modification-functions.html#function_json-set],
> see the discussion of
> [{{JSON_SET()}}|https://dev.mysql.com/doc/refman/5.7/en/json-modification-functions.html#function_json-set].
> JSON_INSERT SQL:
> {code:java}
> SELECT JSON_INSERT(v, '$.a', 10, '$.c', '[true, false]') AS c1
> FROM (VALUES ('{ "a": 1, "b": [2, 3]}')) AS t(v);{code}
> Result:
> ||c1||
> |{"a": 1, "b": [2, 3], "c": "[true, false]"}|
> JSON_REPLACE SQL:
> {code:java}
> SELECT JSON_REPLACE(v, '$.a', 10, '$.c', '[true, false]') AS c1
> FROM (VALUES ('{ "a": 1, "b": [2, 3]}')) AS t(v);{code}
> Result:
> ||c1||
> |{"a": 10, "b": [2, 3],}|
> JSON_SET SQL:
> {code:java}
> SELECT JSON_INSERT(v, '$.a', 10, '$.c', '[true, false]') AS c1
> FROM (VALUES ('{ "a": 1, "b": [2, 3]}')) AS t(v);{code}
> Result:
> ||c1||
> |{"a": 10, "b": [2, 3], "c": "[true, false]"}|
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2975) Implement JSON_REMOVE function
[
https://issues.apache.org/jira/browse/CALCITE-2975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16841347#comment-16841347
]
Hongze Zhang commented on CALCITE-2975:
---
Changed the title to "Implement JSON_REMOVE function". We can use the word
"implement" in future issues/PRs.
> Implement JSON_REMOVE function
> --
>
> Key: CALCITE-2975
> URL: https://issues.apache.org/jira/browse/CALCITE-2975
> Project: Calcite
> Issue Type: Sub-task
>Reporter: Forward Xu
>Assignee: Forward Xu
>Priority: Major
> Labels: pull-request-available
> Time Spent: 3h 20m
> Remaining Estimate: 0h
>
> JSON_REMOVE(json_doc, path[, path] ...)
> Removes data from a JSON document and returns the result. Returns NULL if any
> argument is NULL. An error occurs if the json_doc argument is not a valid
> JSON document or any path argument is not a valid path expression or is $ or
> contains a * or ** wildcard.
> The path arguments are evaluated left to right. The document produced by
> evaluating one path becomes the new value against which the next path is
> evaluated.
> It is not an error if the element to be removed does not exist in the
> document; in that case, the path does not affect the document.
> JSON_REMOVE SQL:
> {code:java}
> SELECT JSON_REMOVE(v, '$[1]') AS c1
> FROM (VALUES ('["a", ["b", "c"], "d"]')) AS t(v);
> {code}
> RESULT:
> ||c1||
> |["a", "d"]|
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CALCITE-2975) Implement JSON_REMOVE function
[
https://issues.apache.org/jira/browse/CALCITE-2975?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hongze Zhang updated CALCITE-2975:
--
Summary: Implement JSON_REMOVE function (was: Add the JSON_REMOVE function)
> Implement JSON_REMOVE function
> --
>
> Key: CALCITE-2975
> URL: https://issues.apache.org/jira/browse/CALCITE-2975
> Project: Calcite
> Issue Type: Sub-task
>Reporter: Forward Xu
>Assignee: Forward Xu
>Priority: Major
> Labels: pull-request-available
> Time Spent: 3h 20m
> Remaining Estimate: 0h
>
> JSON_REMOVE(json_doc, path[, path] ...)
> Removes data from a JSON document and returns the result. Returns NULL if any
> argument is NULL. An error occurs if the json_doc argument is not a valid
> JSON document or any path argument is not a valid path expression or is $ or
> contains a * or ** wildcard.
> The path arguments are evaluated left to right. The document produced by
> evaluating one path becomes the new value against which the next path is
> evaluated.
> It is not an error if the element to be removed does not exist in the
> document; in that case, the path does not affect the document.
> JSON_REMOVE SQL:
> {code:java}
> SELECT JSON_REMOVE(v, '$[1]') AS c1
> FROM (VALUES ('["a", ["b", "c"], "d"]')) AS t(v);
> {code}
> RESULT:
> ||c1||
> |["a", "d"]|
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (CALCITE-3069) Make the JDBC Connection more extensible like the FrameworkConfig API
[ https://issues.apache.org/jira/browse/CALCITE-3069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16840357#comment-16840357 ] Hongze Zhang edited comment on CALCITE-3069 at 5/15/19 12:52 PM: - I happened to have a ongoing work on the extensibility of Framework API, see the PR[1] under CALCITE-2866. To solve that issue, earlier I used to try adding some more options accordingly to CalciteConnectionConfig, as well as to Framework API, afterwards I gave up because I got inclined to treat the JDBC layer more user-oriented, whereas the Framework API is more developer-oriented. So I think it is better not to expose too much low level details in the former at this time (but not 100% sure, if we think having those options configurable via JDBC is also important I'll make further changes for it). Also, in an architectural sense I think the implementation of Calcite JDBC can be integrated with Framework API / Planner API. These APIs are well tested but not used by Calcite itself, even currently you can find the Framework API calls JDBC API internally, where I'll suggest to do things reversely such as forcing Calcite JDBC to use Planner, that might be a lot of work but seems to be reasonable to do. [1] https://github.com/apache/calcite/pull/1145 was (Author: zhztheplayer): I happened to have a ongoing work on the extensibility of Framework API, see the PR[1] under CALCITE-2866. To solve that issue, earlier I used to try adding some more options accordingly to CalciteConnectionConfig, as well as to Framework API, afterwards I gave up because I got inclined to treat the JDBC layer more user-oriented, whereas the Framework API is more developer-oriented. So I think it is better not to expose too much low level details in the former at this time (but not 100% sure, if we think having things configurable via JDBC is also important I'll make further changes for it). Also, in an architectural sense I think the implementation of Calcite JDBC can be integrated with Framework API / Planner API. These APIs are well tested but not used by Calcite itself, even currently you can find the Framework API calls JDBC API internally, where I'll suggest to do things reversely such as forcing Calcite JDBC to use Planner, that might be a lot of work but seems to be reasonable to do. [1] https://github.com/apache/calcite/pull/1145 > Make the JDBC Connection more extensible like the FrameworkConfig API > - > > Key: CALCITE-3069 > URL: https://issues.apache.org/jira/browse/CALCITE-3069 > Project: Calcite > Issue Type: Improvement > Components: core >Affects Versions: 1.19.0 >Reporter: Lai Zhou >Priority: Major > > More and more users are interested in building custom sql engines on top of > Calcite. > But for different sql engines, there're differences on sql parsing, > expression conversions, implicit type casting ...even the physical > implementations for logical plan. > I think the FrameworkConfig API now provided a better way than JDBC > Connection to custom these things.Are there any plans in the roadmap to > enhance the JDBC Connection config , like FrameworkConfig API , to improve > Calcite's extensibility ? > Otherwise, implementing the whole physical plan like the default > Enumerable-implementation will be boring , that also require a lot of work. > May be we can do something to make the physical and execution plan(that says > code-gen ) more customizable. > Are there any thoughts on this issue? > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (CALCITE-3069) Make the JDBC Connection more extensible like the FrameworkConfig API
[ https://issues.apache.org/jira/browse/CALCITE-3069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16840357#comment-16840357 ] Hongze Zhang edited comment on CALCITE-3069 at 5/15/19 12:51 PM: - I happened to have a ongoing work on the extensibility of Framework API, see the PR[1] under CALCITE-2866. To solve that issue, earlier I used to try adding some more options accordingly to CalciteConnectionConfig, as well as to Framework API, afterwards I gave up because I got inclined to treat the JDBC layer more user-oriented, whereas the Framework API is more developer-oriented. So I think it is better not to expose too much low level details in the former at this time (but not 100% sure, if we think having things configurable via JDBC is also important I'll make further changes for it). Also, in an architectural sense I think the implementation of Calcite JDBC can be integrated with Framework API / Planner API. These APIs are well tested but not used by Calcite itself, even currently you can find the Framework API calls JDBC API internally, where I'll suggest to do things reversely such as forcing Calcite JDBC to use Planner, that might be a lot of work but seems to be reasonable to do. [1] https://github.com/apache/calcite/pull/1145 was (Author: zhztheplayer): I happened to have a ongoing work on the extensibility of Framework API, see the PR[1] under CALCITE-2866. To solve that issue, earlier I used to try adding some more options accordingly to CalciteConnectionConfig, as well as to Framework API, afterwards I gave up because I got inclined to treat the JDBC layer more user-oriented, whereas the Framework API is more developer-oriented. So I think it is better not to expose too much low level details in the former at this time. Also, in an architectural sense I think the implementation of Calcite JDBC can be integrated with Framework API / Planner API. These APIs are well tested but not used by Calcite itself, even currently you can find the Framework API calls JDBC API internally, where I'll suggest to do things reversely such as forcing Calcite JDBC to use Planner, that might be a lot of work but seems to be reasonable to do. [1] https://github.com/apache/calcite/pull/1145 > Make the JDBC Connection more extensible like the FrameworkConfig API > - > > Key: CALCITE-3069 > URL: https://issues.apache.org/jira/browse/CALCITE-3069 > Project: Calcite > Issue Type: Improvement > Components: core >Affects Versions: 1.19.0 >Reporter: Lai Zhou >Priority: Major > > More and more users are interested in building custom sql engines on top of > Calcite. > But for different sql engines, there're differences on sql parsing, > expression conversions, implicit type casting ...even the physical > implementations for logical plan. > I think the FrameworkConfig API now provided a better way than JDBC > Connection to custom these things.Are there any plans in the roadmap to > enhance the JDBC Connection config , like FrameworkConfig API , to improve > Calcite's extensibility ? > Otherwise, implementing the whole physical plan like the default > Enumerable-implementation will be boring , that also require a lot of work. > May be we can do something to make the physical and execution plan(that says > code-gen ) more customizable. > Are there any thoughts on this issue? > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-3069) Make the JDBC Connection more extensible like the FrameworkConfig API
[ https://issues.apache.org/jira/browse/CALCITE-3069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16840357#comment-16840357 ] Hongze Zhang commented on CALCITE-3069: --- I happened to have a ongoing work on the extensibility of Framework API, see the PR[1] under CALCITE-2866. To solve that issue, earlier I used to try adding some more options accordingly to CalciteConnectionConfig, as well as to Framework API, afterwards I gave up because I got inclined to treat the JDBC layer more user-oriented, whereas the Framework API is more developer-oriented. So I think it is better not to expose too much low level details in the former at this time. Also, in an architectural sense I think the implementation of Calcite JDBC can be integrated with Framework API / Planner API. These APIs are well tested but not used by Calcite itself, even currently you can find the Framework API calls JDBC API internally, where I'll suggest to do things reversely such as forcing Calcite JDBC to use Planner, that might be a lot of work but seems to be reasonable to do. [1] https://github.com/apache/calcite/pull/1145 > Make the JDBC Connection more extensible like the FrameworkConfig API > - > > Key: CALCITE-3069 > URL: https://issues.apache.org/jira/browse/CALCITE-3069 > Project: Calcite > Issue Type: Improvement > Components: core >Affects Versions: 1.19.0 >Reporter: Lai Zhou >Priority: Major > > More and more users are interested in building custom sql engines on top of > Calcite. > But for different sql engines, there're differences on sql parsing, > expression conversions, implicit type casting ...even the physical > implementations for logical plan. > I think the FrameworkConfig API now provided a better way than JDBC > Connection to custom these things.Are there any plans in the roadmap to > enhance the JDBC Connection config , like FrameworkConfig API , to improve > Calcite's extensibility ? > Otherwise, implementing the whole physical plan like the default > Enumerable-implementation will be boring , that also require a lot of work. > May be we can do something to make the physical and execution plan(that says > code-gen ) more customizable. > Are there any thoughts on this issue? > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (CALCITE-3017) Improve null handling of JsonValueExpressionOperator
[
https://issues.apache.org/jira/browse/CALCITE-3017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hongze Zhang resolved CALCITE-3017.
---
Resolution: Fixed
Fixed in
[e98c779d1ec0bc87c81a72b974c89a41a7222a07|https://github.com/apache/calcite/commit/e98c779d1ec0bc87c81a72b974c89a41a7222a07].
> 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: 1.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)
[jira] [Commented] (CALCITE-3017) Improve null handling of JsonValueExpressionOperator
[
https://issues.apache.org/jira/browse/CALCITE-3017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16838458#comment-16838458
]
Hongze Zhang commented on CALCITE-3017:
---
Since the issue blocks the attempt on rebasing fix of CALCITE-2985, I am
inclined to merge the PR soon (maybe before 1.20.0 release, it would be great
if someone wants to help to review :)).
A little bit more:
Some JSON functions are more complicated than regular functions, as they
always allow some user-specified flags to customize behaviors during the
execution process, such as input format, implicit input format, output format,
error handling, null handling, and so on. However to myself it is more
important to make the code simple and readable than to prepare changes for all
possible functionalities. If there are too much nested structures in function
parameter list, then more hardness will be brought to user when implementing
these functions. This is also one of the reason why removing several operators
(such as {{JSON_STRUCTURED_VALUE_EXPRESSION}},
{{JSON_API_COMMON_SYNTAX_WITHOUT_PATH}}, {{JSON_VALUE_EXPRESSION}}) in recent
code changes of JSON support.
> 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: 1h
> 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)
[jira] [Comment Edited] (CALCITE-35) Support parenthesized sub-clause in JOIN
[
https://issues.apache.org/jira/browse/CALCITE-35?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16838007#comment-16838007
]
Hongze Zhang edited comment on CALCITE-35 at 5/12/19 9:21 AM:
--
Thanks Muhammad. I think the case should work properly this time. However the
syntactic lookahead {{LOOKAHEAD(TableRef())}} brings quadratic behavior
(O(n^2)) in parsing. Do we have chance to reduce it back to liner (O\(n\))? I
suppose this was one of the main problems that block our effort on solving this
issue before.
was (Author: zhztheplayer):
Thanks Muhammad. I think the case should work properly this time. However the
syntactic lookahead {{LOOKAHEAD(TableRef())}} brings quadratic behavior
(O(n^2)) in parsing. Do we have chance to reduce it back to liner (O(n))? I
suppose this was one of the main problems that block our effort on solving this
issue before.
> Support parenthesized sub-clause in JOIN
>
>
> Key: CALCITE-35
> URL: https://issues.apache.org/jira/browse/CALCITE-35
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.19.0
>Reporter: GitHub Import
>Priority: Major
> Labels: github-import, pull-request-available
> Time Spent: 50m
> Remaining Estimate: 0h
>
> SQL-92 allows joins to be grouped into trees using parentheses. For example,
> select * from a join (b join c on b.x = c.x) on a.y = c.y
> Optiq should support this. Currently this gives
> "org.eigenbase.util.EigenbaseException: Non-query expression encountered in
> illegal context".
> Imported from GitHub
> Url: https://github.com/julianhyde/optiq/issues/35
> Created by: [julianhyde|https://github.com/julianhyde]
> Labels:
> Created at: Fri Apr 19 02:46:01 CEST 2013
> State: open
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (CALCITE-35) Support parenthesized sub-clause in JOIN
[
https://issues.apache.org/jira/browse/CALCITE-35?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16838007#comment-16838007
]
Hongze Zhang edited comment on CALCITE-35 at 5/12/19 9:20 AM:
--
Thanks Muhammad. I think the case should work properly this time. However the
syntactic lookahead {{LOOKAHEAD(TableRef())}} brings quadratic behavior
(O(n^2)) in parsing. Do we have chance to reduce it back to liner (O(n))? I
suppose this was one of the main problems that block our effort on solving this
issue before.
was (Author: zhztheplayer):
Thanks Muhammad. I think the case should work properly this time. However the
semantic lookahead {{LOOKAHEAD(TableRef())}} brings quadratic behavior (O(n^2))
in parsing. Do we have chance to reduce it back to liner (O\(n\))? I suppose
this was one of the main problems that block our effort on solving this issue
before.
> Support parenthesized sub-clause in JOIN
>
>
> Key: CALCITE-35
> URL: https://issues.apache.org/jira/browse/CALCITE-35
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.19.0
>Reporter: GitHub Import
>Priority: Major
> Labels: github-import, pull-request-available
> Time Spent: 50m
> Remaining Estimate: 0h
>
> SQL-92 allows joins to be grouped into trees using parentheses. For example,
> select * from a join (b join c on b.x = c.x) on a.y = c.y
> Optiq should support this. Currently this gives
> "org.eigenbase.util.EigenbaseException: Non-query expression encountered in
> illegal context".
> Imported from GitHub
> Url: https://github.com/julianhyde/optiq/issues/35
> Created by: [julianhyde|https://github.com/julianhyde]
> Labels:
> Created at: Fri Apr 19 02:46:01 CEST 2013
> State: open
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-35) Support parenthesized sub-clause in JOIN
[
https://issues.apache.org/jira/browse/CALCITE-35?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16838007#comment-16838007
]
Hongze Zhang commented on CALCITE-35:
-
Thanks Muhammad. I think the case should work properly this time. However the
semantic lookahead {{LOOKAHEAD(TableRef())}} brings quadratic behavior (O(n^2))
in parsing. Do we have chance to reduce it back to liner (O\(n\))? I suppose
this was one of the main problems that block our effort on solving this issue
before.
> Support parenthesized sub-clause in JOIN
>
>
> Key: CALCITE-35
> URL: https://issues.apache.org/jira/browse/CALCITE-35
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.19.0
>Reporter: GitHub Import
>Priority: Major
> Labels: github-import, pull-request-available
> Time Spent: 50m
> Remaining Estimate: 0h
>
> SQL-92 allows joins to be grouped into trees using parentheses. For example,
> select * from a join (b join c on b.x = c.x) on a.y = c.y
> Optiq should support this. Currently this gives
> "org.eigenbase.util.EigenbaseException: Non-query expression encountered in
> illegal context".
> Imported from GitHub
> Url: https://github.com/julianhyde/optiq/issues/35
> Created by: [julianhyde|https://github.com/julianhyde]
> Labels:
> Created at: Fri Apr 19 02:46:01 CEST 2013
> State: open
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-35) Support parenthesized sub-clause in JOIN
[
https://issues.apache.org/jira/browse/CALCITE-35?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16837885#comment-16837885
]
Hongze Zhang commented on CALCITE-35:
-
Thanks for the PR [~mgelbana]! I just took a quick look at the changes, which
seems to be reasonable but still not able to solve the documented problem[1] of
difficulty on setting correct lookahead for table references. I see Julian has
also mentioned the problem in previous comments.
To figure out the problem in the fix, I suggest to add a test case like
following:
{code:sql}
SELECT * FROM (((SELECT * FROM tab)))
{code}
or even more left brackets:
{code:sql}
SELECT * FROM ((SELECT * FROM tab))
{code}
Generally these cases should be parsed successfully before and after applying
the fix.
[1]
https://github.com/apache/calcite/blob/b15c8c9baccf05e1bf16b1e268d4edfac90bbf03/core/src/main/codegen/templates/Parser.jj#L339-L348
> Support parenthesized sub-clause in JOIN
>
>
> Key: CALCITE-35
> URL: https://issues.apache.org/jira/browse/CALCITE-35
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.19.0
>Reporter: GitHub Import
>Priority: Major
> Labels: github-import, pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> SQL-92 allows joins to be grouped into trees using parentheses. For example,
> select * from a join (b join c on b.x = c.x) on a.y = c.y
> Optiq should support this. Currently this gives
> "org.eigenbase.util.EigenbaseException: Non-query expression encountered in
> illegal context".
> Imported from GitHub
> Url: https://github.com/julianhyde/optiq/issues/35
> Created by: [julianhyde|https://github.com/julianhyde]
> Labels:
> Created at: Fri Apr 19 02:46:01 CEST 2013
> State: open
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-3017) Improve null handling of JsonValueExpressionOperator
[
https://issues.apache.org/jira/browse/CALCITE-3017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16836153#comment-16836153
]
Hongze Zhang commented on CALCITE-3017:
---
PR opened at https://github.com/apache/calcite/pull/1203.
> 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)
[jira] [Resolved] (CALCITE-3046) CompileException when inserting casted value of composited user defined type into table
[
https://issues.apache.org/jira/browse/CALCITE-3046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hongze Zhang resolved CALCITE-3046.
---
Resolution: Fixed
Assignee: Hongze Zhang
Fix Version/s: 1.20.0
Fixed in
[b8bdfb074be12f90c98f9f1fa2af8cf46f2d36f1|https://github.com/apache/calcite/commit/b8bdfb074be12f90c98f9f1fa2af8cf46f2d36f1].
> CompileException when inserting casted value of composited user defined type
> into table
> ---
>
> Key: CALCITE-3046
> URL: https://issues.apache.org/jira/browse/CALCITE-3046
> Project: Calcite
> Issue Type: Bug
>Reporter: Hongze Zhang
>Assignee: Hongze Zhang
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.20.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Reproduce the error by running following test case from {{ServerTest.java}}:
> {code:java}
> @Test public void testInsertCastedValueOfCompositeUdt() throws Exception {
> try (Connection c = connect();
> Statement s = c.createStatement()) {
> boolean b = s.execute("create type mytype as (i int, j int)");
> assertThat(b, is(false));
> b = s.execute("create table w (i int not null, j mytype)");
> assertThat(b, is(false));
> int x = s.executeUpdate("insert into w "
> + "values (1, cast((select j from w) as mytype))");
> assertThat(x, is(1));
> }
> }
> {code}
> Root cause of the error:
> {code}
> Caused by: org.codehaus.commons.compiler.CompileException: Line 96, Column
> 84: Cannot determine simple type name "Record2_0"
> at
> org.codehaus.janino.UnitCompiler.compileError(UnitCompiler.java:12211)
> at
> org.codehaus.janino.UnitCompiler.getReferenceType(UnitCompiler.java:6833)
> at
> org.codehaus.janino.UnitCompiler.getReferenceType(UnitCompiler.java:6594)
> at org.codehaus.janino.UnitCompiler.getType2(UnitCompiler.java:6573)
> at org.codehaus.janino.UnitCompiler.access$13900(UnitCompiler.java:215)
> at
> org.codehaus.janino.UnitCompiler$22$1.visitReferenceType(UnitCompiler.java:6481)
> at
> org.codehaus.janino.UnitCompiler$22$1.visitReferenceType(UnitCompiler.java:6476)
> at org.codehaus.janino.Java$ReferenceType.accept(Java.java:3928)
> at org.codehaus.janino.UnitCompiler$22.visitType(UnitCompiler.java:6476)
> at org.codehaus.janino.UnitCompiler$22.visitType(UnitCompiler.java:6469)
> at org.codehaus.janino.Java$ReferenceType.accept(Java.java:3927)
> at org.codehaus.janino.UnitCompiler.getType(UnitCompiler.java:6469)
> at org.codehaus.janino.UnitCompiler.access$1300(UnitCompiler.java:215)
> at
> org.codehaus.janino.UnitCompiler$36.getParameterTypes2(UnitCompiler.java:10383)
> at
> org.codehaus.janino.IClass$IInvocable.getParameterTypes(IClass.java:960)
> at org.codehaus.janino.IClass$IMethod.getDescriptor2(IClass.java:1227)
> at org.codehaus.janino.IClass$IInvocable.getDescriptor(IClass.java:983)
> at org.codehaus.janino.IClass.getIMethods(IClass.java:248)
> at org.codehaus.janino.IClass.getIMethods(IClass.java:237)
> at org.codehaus.janino.UnitCompiler.compile2(UnitCompiler.java:492)
> at org.codehaus.janino.UnitCompiler.compile2(UnitCompiler.java:981)
> at org.codehaus.janino.UnitCompiler.compile2(UnitCompiler.java:951)
> at org.codehaus.janino.UnitCompiler.access$200(UnitCompiler.java:215)
> at
> org.codehaus.janino.UnitCompiler$2.visitAnonymousClassDeclaration(UnitCompiler.java:409)
> at
> org.codehaus.janino.UnitCompiler$2.visitAnonymousClassDeclaration(UnitCompiler.java:406)
> at
> org.codehaus.janino.Java$AnonymousClassDeclaration.accept(Java.java:1149)
> at org.codehaus.janino.UnitCompiler.compile(UnitCompiler.java:406)
> at org.codehaus.janino.UnitCompiler.compileGet2(UnitCompiler.java:5509)
> at org.codehaus.janino.UnitCompiler.access$9500(UnitCompiler.java:215)
> at
> org.codehaus.janino.UnitCompiler$16.visitNewAnonymousClassInstance(UnitCompiler.java:4432)
> at
> org.codehaus.janino.UnitCompiler$16.visitNewAnonymousClassInstance(UnitCompiler.java:4396)
> at
> org.codehaus.janino.Java$NewAnonymousClassInstance.accept(Java.java:5238)
> at org.codehaus.janino.UnitCompiler.compileGet(UnitCompiler.java:4396)
> at
> org.codehaus.janino.UnitCompiler.compileGetValue(UnitCompiler.java:5662)
> at org.codehaus.janino.UnitCompiler.compileGet2(UnitCompiler.java:5182)
> at org.codehaus.janino.UnitCompiler.access$9100(UnitCompiler.java:215)
> at
> org.codehaus.janino.UnitCompiler$16.visitMethodInvocation(UnitCompiler.java:4423)
> at
>
[jira] [Commented] (CALCITE-3046) CompileException when inserting casted value of composited user defined type into table
[
https://issues.apache.org/jira/browse/CALCITE-3046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16834840#comment-16834840
]
Hongze Zhang commented on CALCITE-3046:
---
As what's been suggested, I've added some extra visiting logic to
EnumerableRelImplementor.TypeFinder, and per content of the changes the overall
performance should not be affected much.
* visit typed null literal, e.g. MyType type = (MyType) null;
* visit convert expression, e.g. MyType type = (MyType) obj;
* visit linq4j {{FunctionExpression}} (this fixes the error described in the
issue topic/description)
> CompileException when inserting casted value of composited user defined type
> into table
> ---
>
> Key: CALCITE-3046
> URL: https://issues.apache.org/jira/browse/CALCITE-3046
> Project: Calcite
> Issue Type: Bug
>Reporter: Hongze Zhang
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Reproduce the error by running following test case from {{ServerTest.java}}:
> {code:java}
> @Test public void testInsertCastedValueOfCompositeUdt() throws Exception {
> try (Connection c = connect();
> Statement s = c.createStatement()) {
> boolean b = s.execute("create type mytype as (i int, j int)");
> assertThat(b, is(false));
> b = s.execute("create table w (i int not null, j mytype)");
> assertThat(b, is(false));
> int x = s.executeUpdate("insert into w "
> + "values (1, cast((select j from w) as mytype))");
> assertThat(x, is(1));
> }
> }
> {code}
> Root cause of the error:
> {code}
> Caused by: org.codehaus.commons.compiler.CompileException: Line 96, Column
> 84: Cannot determine simple type name "Record2_0"
> at
> org.codehaus.janino.UnitCompiler.compileError(UnitCompiler.java:12211)
> at
> org.codehaus.janino.UnitCompiler.getReferenceType(UnitCompiler.java:6833)
> at
> org.codehaus.janino.UnitCompiler.getReferenceType(UnitCompiler.java:6594)
> at org.codehaus.janino.UnitCompiler.getType2(UnitCompiler.java:6573)
> at org.codehaus.janino.UnitCompiler.access$13900(UnitCompiler.java:215)
> at
> org.codehaus.janino.UnitCompiler$22$1.visitReferenceType(UnitCompiler.java:6481)
> at
> org.codehaus.janino.UnitCompiler$22$1.visitReferenceType(UnitCompiler.java:6476)
> at org.codehaus.janino.Java$ReferenceType.accept(Java.java:3928)
> at org.codehaus.janino.UnitCompiler$22.visitType(UnitCompiler.java:6476)
> at org.codehaus.janino.UnitCompiler$22.visitType(UnitCompiler.java:6469)
> at org.codehaus.janino.Java$ReferenceType.accept(Java.java:3927)
> at org.codehaus.janino.UnitCompiler.getType(UnitCompiler.java:6469)
> at org.codehaus.janino.UnitCompiler.access$1300(UnitCompiler.java:215)
> at
> org.codehaus.janino.UnitCompiler$36.getParameterTypes2(UnitCompiler.java:10383)
> at
> org.codehaus.janino.IClass$IInvocable.getParameterTypes(IClass.java:960)
> at org.codehaus.janino.IClass$IMethod.getDescriptor2(IClass.java:1227)
> at org.codehaus.janino.IClass$IInvocable.getDescriptor(IClass.java:983)
> at org.codehaus.janino.IClass.getIMethods(IClass.java:248)
> at org.codehaus.janino.IClass.getIMethods(IClass.java:237)
> at org.codehaus.janino.UnitCompiler.compile2(UnitCompiler.java:492)
> at org.codehaus.janino.UnitCompiler.compile2(UnitCompiler.java:981)
> at org.codehaus.janino.UnitCompiler.compile2(UnitCompiler.java:951)
> at org.codehaus.janino.UnitCompiler.access$200(UnitCompiler.java:215)
> at
> org.codehaus.janino.UnitCompiler$2.visitAnonymousClassDeclaration(UnitCompiler.java:409)
> at
> org.codehaus.janino.UnitCompiler$2.visitAnonymousClassDeclaration(UnitCompiler.java:406)
> at
> org.codehaus.janino.Java$AnonymousClassDeclaration.accept(Java.java:1149)
> at org.codehaus.janino.UnitCompiler.compile(UnitCompiler.java:406)
> at org.codehaus.janino.UnitCompiler.compileGet2(UnitCompiler.java:5509)
> at org.codehaus.janino.UnitCompiler.access$9500(UnitCompiler.java:215)
> at
> org.codehaus.janino.UnitCompiler$16.visitNewAnonymousClassInstance(UnitCompiler.java:4432)
> at
> org.codehaus.janino.UnitCompiler$16.visitNewAnonymousClassInstance(UnitCompiler.java:4396)
> at
> org.codehaus.janino.Java$NewAnonymousClassInstance.accept(Java.java:5238)
> at org.codehaus.janino.UnitCompiler.compileGet(UnitCompiler.java:4396)
> at
> org.codehaus.janino.UnitCompiler.compileGetValue(UnitCompiler.java:5662)
> at org.codehaus.janino.UnitCompiler.compileGet2(UnitCompiler.java:5182)
> at org.codehaus.janino.UnitCompiler.access$9100(UnitCompiler.java:215)
> at
>
[jira] [Commented] (CALCITE-3010) In SQL parser, move JsonValueExpression into Expression
[
https://issues.apache.org/jira/browse/CALCITE-3010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16833246#comment-16833246
]
Hongze Zhang commented on CALCITE-3010:
---
Removed in a follow up commit
[0d504d|https://github.com/apache/calcite/commit/0d504d20d47542e8d461982512ae0e7a94e4d6cb].
So sorry for the mistake.
> In SQL parser, move JsonValueExpression into Expression
> ---
>
> Key: CALCITE-3010
> URL: https://issues.apache.org/jira/browse/CALCITE-3010
> 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: 20m
> Remaining Estimate: 0h
>
> Below is the syntax definition of {{JsonValueExpression}} from ISO/SEC
> 19075-6:
> {code:java}
> ::=
>[ ]
> ::=
> FORMAT
> ::=
> JSON [ ENCODING { UTF8 | UTF16 | UTF32 } ]
> |
> {code}
> Currently it's an individual syntax standing out of {{Expression}} for easily
> implementing the behavior of "implicit JSON format". As the amount of JSON
> functions is getting larger, the design could definitely be improved. For
> example, it can be categorized as a PostfixOperator[1].
> [1]
> [https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/sql/SqlPostfixOperator.java]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CALCITE-3046) CompileException when inserting casted value of composited user defined type to table
[
https://issues.apache.org/jira/browse/CALCITE-3046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hongze Zhang updated CALCITE-3046:
--
Summary: CompileException when inserting casted value of composited user
defined type to table (was: CompileException when inserting casted value of
composited user defined type)
> CompileException when inserting casted value of composited user defined type
> to table
> -
>
> Key: CALCITE-3046
> URL: https://issues.apache.org/jira/browse/CALCITE-3046
> Project: Calcite
> Issue Type: Bug
>Reporter: Hongze Zhang
>Priority: Major
>
> Reproduce the error by running following test case from {{ServerTest.java}}:
> {code:java}
> @Test public void testInsertCastedValueOfCompositeUdt() throws Exception {
> try (Connection c = connect();
> Statement s = c.createStatement()) {
> boolean b = s.execute("create type mytype as (i int, j int)");
> assertThat(b, is(false));
> b = s.execute("create table w (i int not null, j mytype)");
> assertThat(b, is(false));
> int x = s.executeUpdate("insert into w "
> + "values (1, cast((select j from w) as mytype))");
> assertThat(x, is(1));
> }
> }
> {code}
> Root cause of the error:
> {code}
> Caused by: org.codehaus.commons.compiler.CompileException: Line 96, Column
> 84: Cannot determine simple type name "Record2_0"
> at
> org.codehaus.janino.UnitCompiler.compileError(UnitCompiler.java:12211)
> at
> org.codehaus.janino.UnitCompiler.getReferenceType(UnitCompiler.java:6833)
> at
> org.codehaus.janino.UnitCompiler.getReferenceType(UnitCompiler.java:6594)
> at org.codehaus.janino.UnitCompiler.getType2(UnitCompiler.java:6573)
> at org.codehaus.janino.UnitCompiler.access$13900(UnitCompiler.java:215)
> at
> org.codehaus.janino.UnitCompiler$22$1.visitReferenceType(UnitCompiler.java:6481)
> at
> org.codehaus.janino.UnitCompiler$22$1.visitReferenceType(UnitCompiler.java:6476)
> at org.codehaus.janino.Java$ReferenceType.accept(Java.java:3928)
> at org.codehaus.janino.UnitCompiler$22.visitType(UnitCompiler.java:6476)
> at org.codehaus.janino.UnitCompiler$22.visitType(UnitCompiler.java:6469)
> at org.codehaus.janino.Java$ReferenceType.accept(Java.java:3927)
> at org.codehaus.janino.UnitCompiler.getType(UnitCompiler.java:6469)
> at org.codehaus.janino.UnitCompiler.access$1300(UnitCompiler.java:215)
> at
> org.codehaus.janino.UnitCompiler$36.getParameterTypes2(UnitCompiler.java:10383)
> at
> org.codehaus.janino.IClass$IInvocable.getParameterTypes(IClass.java:960)
> at org.codehaus.janino.IClass$IMethod.getDescriptor2(IClass.java:1227)
> at org.codehaus.janino.IClass$IInvocable.getDescriptor(IClass.java:983)
> at org.codehaus.janino.IClass.getIMethods(IClass.java:248)
> at org.codehaus.janino.IClass.getIMethods(IClass.java:237)
> at org.codehaus.janino.UnitCompiler.compile2(UnitCompiler.java:492)
> at org.codehaus.janino.UnitCompiler.compile2(UnitCompiler.java:981)
> at org.codehaus.janino.UnitCompiler.compile2(UnitCompiler.java:951)
> at org.codehaus.janino.UnitCompiler.access$200(UnitCompiler.java:215)
> at
> org.codehaus.janino.UnitCompiler$2.visitAnonymousClassDeclaration(UnitCompiler.java:409)
> at
> org.codehaus.janino.UnitCompiler$2.visitAnonymousClassDeclaration(UnitCompiler.java:406)
> at
> org.codehaus.janino.Java$AnonymousClassDeclaration.accept(Java.java:1149)
> at org.codehaus.janino.UnitCompiler.compile(UnitCompiler.java:406)
> at org.codehaus.janino.UnitCompiler.compileGet2(UnitCompiler.java:5509)
> at org.codehaus.janino.UnitCompiler.access$9500(UnitCompiler.java:215)
> at
> org.codehaus.janino.UnitCompiler$16.visitNewAnonymousClassInstance(UnitCompiler.java:4432)
> at
> org.codehaus.janino.UnitCompiler$16.visitNewAnonymousClassInstance(UnitCompiler.java:4396)
> at
> org.codehaus.janino.Java$NewAnonymousClassInstance.accept(Java.java:5238)
> at org.codehaus.janino.UnitCompiler.compileGet(UnitCompiler.java:4396)
> at
> org.codehaus.janino.UnitCompiler.compileGetValue(UnitCompiler.java:5662)
> at org.codehaus.janino.UnitCompiler.compileGet2(UnitCompiler.java:5182)
> at org.codehaus.janino.UnitCompiler.access$9100(UnitCompiler.java:215)
> at
> org.codehaus.janino.UnitCompiler$16.visitMethodInvocation(UnitCompiler.java:4423)
> at
> org.codehaus.janino.UnitCompiler$16.visitMethodInvocation(UnitCompiler.java:4396)
> at org.codehaus.janino.Java$MethodInvocation.accept(Java.java:5073)
> at org.codehaus.janino.UnitCompiler.compileGet(UnitCompiler.java:4396)
> at
>
[jira] [Commented] (CALCITE-3046) CompileException when inserting casted value of composited user defined type
[
https://issues.apache.org/jira/browse/CALCITE-3046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16831423#comment-16831423
]
Hongze Zhang commented on CALCITE-3046:
---
This is another problem of UDT implementation, not related to CALCITE-3045.
My assumption is that we can fix this issue by make
EnumerableRelImplementor.TypeFinder visit more parts of the expression tree
(such as the type of ConstantExpression, UnaryExpression of "Convert"), however
not sure if the execution performance would be decreased too much.
> CompileException when inserting casted value of composited user defined type
>
>
> Key: CALCITE-3046
> URL: https://issues.apache.org/jira/browse/CALCITE-3046
> Project: Calcite
> Issue Type: Bug
>Reporter: Hongze Zhang
>Priority: Major
>
> Reproduce the error by running following test case from {{ServerTest.java}}:
> {code:java}
> @Test public void testInsertCastedValueOfCompositeUdt() throws Exception {
> try (Connection c = connect();
> Statement s = c.createStatement()) {
> // CALCITE-2464: Allow to set nullability for columns of structured
> types
> boolean b = s.execute("create type mytype as (i int, j int)");
> assertThat(b, is(false));
> b = s.execute("create table w (i int not null, j mytype)");
> assertThat(b, is(false));
> int x = s.executeUpdate("insert into w "
> + "values (1, cast((select j from w) as mytype))");
> assertThat(x, is(1));
> }
> }
> {code}
> Root cause of the error:
> {code}
> Caused by: org.codehaus.commons.compiler.CompileException: Line 96, Column
> 84: Cannot determine simple type name "Record2_0"
> at
> org.codehaus.janino.UnitCompiler.compileError(UnitCompiler.java:12211)
> at
> org.codehaus.janino.UnitCompiler.getReferenceType(UnitCompiler.java:6833)
> at
> org.codehaus.janino.UnitCompiler.getReferenceType(UnitCompiler.java:6594)
> at org.codehaus.janino.UnitCompiler.getType2(UnitCompiler.java:6573)
> at org.codehaus.janino.UnitCompiler.access$13900(UnitCompiler.java:215)
> at
> org.codehaus.janino.UnitCompiler$22$1.visitReferenceType(UnitCompiler.java:6481)
> at
> org.codehaus.janino.UnitCompiler$22$1.visitReferenceType(UnitCompiler.java:6476)
> at org.codehaus.janino.Java$ReferenceType.accept(Java.java:3928)
> at org.codehaus.janino.UnitCompiler$22.visitType(UnitCompiler.java:6476)
> at org.codehaus.janino.UnitCompiler$22.visitType(UnitCompiler.java:6469)
> at org.codehaus.janino.Java$ReferenceType.accept(Java.java:3927)
> at org.codehaus.janino.UnitCompiler.getType(UnitCompiler.java:6469)
> at org.codehaus.janino.UnitCompiler.access$1300(UnitCompiler.java:215)
> at
> org.codehaus.janino.UnitCompiler$36.getParameterTypes2(UnitCompiler.java:10383)
> at
> org.codehaus.janino.IClass$IInvocable.getParameterTypes(IClass.java:960)
> at org.codehaus.janino.IClass$IMethod.getDescriptor2(IClass.java:1227)
> at org.codehaus.janino.IClass$IInvocable.getDescriptor(IClass.java:983)
> at org.codehaus.janino.IClass.getIMethods(IClass.java:248)
> at org.codehaus.janino.IClass.getIMethods(IClass.java:237)
> at org.codehaus.janino.UnitCompiler.compile2(UnitCompiler.java:492)
> at org.codehaus.janino.UnitCompiler.compile2(UnitCompiler.java:981)
> at org.codehaus.janino.UnitCompiler.compile2(UnitCompiler.java:951)
> at org.codehaus.janino.UnitCompiler.access$200(UnitCompiler.java:215)
> at
> org.codehaus.janino.UnitCompiler$2.visitAnonymousClassDeclaration(UnitCompiler.java:409)
> at
> org.codehaus.janino.UnitCompiler$2.visitAnonymousClassDeclaration(UnitCompiler.java:406)
> at
> org.codehaus.janino.Java$AnonymousClassDeclaration.accept(Java.java:1149)
> at org.codehaus.janino.UnitCompiler.compile(UnitCompiler.java:406)
> at org.codehaus.janino.UnitCompiler.compileGet2(UnitCompiler.java:5509)
> at org.codehaus.janino.UnitCompiler.access$9500(UnitCompiler.java:215)
> at
> org.codehaus.janino.UnitCompiler$16.visitNewAnonymousClassInstance(UnitCompiler.java:4432)
> at
> org.codehaus.janino.UnitCompiler$16.visitNewAnonymousClassInstance(UnitCompiler.java:4396)
> at
> org.codehaus.janino.Java$NewAnonymousClassInstance.accept(Java.java:5238)
> at org.codehaus.janino.UnitCompiler.compileGet(UnitCompiler.java:4396)
> at
> org.codehaus.janino.UnitCompiler.compileGetValue(UnitCompiler.java:5662)
> at org.codehaus.janino.UnitCompiler.compileGet2(UnitCompiler.java:5182)
> at org.codehaus.janino.UnitCompiler.access$9100(UnitCompiler.java:215)
> at
> org.codehaus.janino.UnitCompiler$16.visitMethodInvocation(UnitCompiler.java:4423)
> at
>
[jira] [Created] (CALCITE-3046) CompileException when inserting casted value of composited user defined type
Hongze Zhang created CALCITE-3046:
-
Summary: CompileException when inserting casted value of
composited user defined type
Key: CALCITE-3046
URL: https://issues.apache.org/jira/browse/CALCITE-3046
Project: Calcite
Issue Type: Bug
Reporter: Hongze Zhang
Reproduce the error by running following test case from {{ServerTest.java}}:
{code:java}
@Test public void testInsertCastedValueOfCompositeUdt() throws Exception {
try (Connection c = connect();
Statement s = c.createStatement()) {
// CALCITE-2464: Allow to set nullability for columns of structured types
boolean b = s.execute("create type mytype as (i int, j int)");
assertThat(b, is(false));
b = s.execute("create table w (i int not null, j mytype)");
assertThat(b, is(false));
int x = s.executeUpdate("insert into w "
+ "values (1, cast((select j from w) as mytype))");
assertThat(x, is(1));
}
}
{code}
Root cause of the error:
{code}
Caused by: org.codehaus.commons.compiler.CompileException: Line 96, Column 84:
Cannot determine simple type name "Record2_0"
at
org.codehaus.janino.UnitCompiler.compileError(UnitCompiler.java:12211)
at
org.codehaus.janino.UnitCompiler.getReferenceType(UnitCompiler.java:6833)
at
org.codehaus.janino.UnitCompiler.getReferenceType(UnitCompiler.java:6594)
at org.codehaus.janino.UnitCompiler.getType2(UnitCompiler.java:6573)
at org.codehaus.janino.UnitCompiler.access$13900(UnitCompiler.java:215)
at
org.codehaus.janino.UnitCompiler$22$1.visitReferenceType(UnitCompiler.java:6481)
at
org.codehaus.janino.UnitCompiler$22$1.visitReferenceType(UnitCompiler.java:6476)
at org.codehaus.janino.Java$ReferenceType.accept(Java.java:3928)
at org.codehaus.janino.UnitCompiler$22.visitType(UnitCompiler.java:6476)
at org.codehaus.janino.UnitCompiler$22.visitType(UnitCompiler.java:6469)
at org.codehaus.janino.Java$ReferenceType.accept(Java.java:3927)
at org.codehaus.janino.UnitCompiler.getType(UnitCompiler.java:6469)
at org.codehaus.janino.UnitCompiler.access$1300(UnitCompiler.java:215)
at
org.codehaus.janino.UnitCompiler$36.getParameterTypes2(UnitCompiler.java:10383)
at
org.codehaus.janino.IClass$IInvocable.getParameterTypes(IClass.java:960)
at org.codehaus.janino.IClass$IMethod.getDescriptor2(IClass.java:1227)
at org.codehaus.janino.IClass$IInvocable.getDescriptor(IClass.java:983)
at org.codehaus.janino.IClass.getIMethods(IClass.java:248)
at org.codehaus.janino.IClass.getIMethods(IClass.java:237)
at org.codehaus.janino.UnitCompiler.compile2(UnitCompiler.java:492)
at org.codehaus.janino.UnitCompiler.compile2(UnitCompiler.java:981)
at org.codehaus.janino.UnitCompiler.compile2(UnitCompiler.java:951)
at org.codehaus.janino.UnitCompiler.access$200(UnitCompiler.java:215)
at
org.codehaus.janino.UnitCompiler$2.visitAnonymousClassDeclaration(UnitCompiler.java:409)
at
org.codehaus.janino.UnitCompiler$2.visitAnonymousClassDeclaration(UnitCompiler.java:406)
at
org.codehaus.janino.Java$AnonymousClassDeclaration.accept(Java.java:1149)
at org.codehaus.janino.UnitCompiler.compile(UnitCompiler.java:406)
at org.codehaus.janino.UnitCompiler.compileGet2(UnitCompiler.java:5509)
at org.codehaus.janino.UnitCompiler.access$9500(UnitCompiler.java:215)
at
org.codehaus.janino.UnitCompiler$16.visitNewAnonymousClassInstance(UnitCompiler.java:4432)
at
org.codehaus.janino.UnitCompiler$16.visitNewAnonymousClassInstance(UnitCompiler.java:4396)
at
org.codehaus.janino.Java$NewAnonymousClassInstance.accept(Java.java:5238)
at org.codehaus.janino.UnitCompiler.compileGet(UnitCompiler.java:4396)
at
org.codehaus.janino.UnitCompiler.compileGetValue(UnitCompiler.java:5662)
at org.codehaus.janino.UnitCompiler.compileGet2(UnitCompiler.java:5182)
at org.codehaus.janino.UnitCompiler.access$9100(UnitCompiler.java:215)
at
org.codehaus.janino.UnitCompiler$16.visitMethodInvocation(UnitCompiler.java:4423)
at
org.codehaus.janino.UnitCompiler$16.visitMethodInvocation(UnitCompiler.java:4396)
at org.codehaus.janino.Java$MethodInvocation.accept(Java.java:5073)
at org.codehaus.janino.UnitCompiler.compileGet(UnitCompiler.java:4396)
at
org.codehaus.janino.UnitCompiler.compileGetValue(UnitCompiler.java:5662)
at org.codehaus.janino.UnitCompiler.compile2(UnitCompiler.java:2580)
at org.codehaus.janino.UnitCompiler.access$2700(UnitCompiler.java:215)
at
org.codehaus.janino.UnitCompiler$6.visitLocalVariableDeclarationStatement(UnitCompiler.java:1503)
at
org.codehaus.janino.UnitCompiler$6.visitLocalVariableDeclarationStatement(UnitCompiler.java:1487)
[jira] [Resolved] (CALCITE-3045) NullPointerException when casting null literal to composite user defined type
[
https://issues.apache.org/jira/browse/CALCITE-3045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hongze Zhang resolved CALCITE-3045.
---
Resolution: Fixed
Assignee: Hongze Zhang
Fixed in
[a8f46239509f01162c4e3ecf640a59cf0e0dfcad|https://gitbox.apache.org/repos/asf?p=calcite.git;a=commit;h=a8f46239509f01162c4e3ecf640a59cf0e0dfcad].
> NullPointerException when casting null literal to composite user defined type
> -
>
> Key: CALCITE-3045
> URL: https://issues.apache.org/jira/browse/CALCITE-3045
> Project: Calcite
> Issue Type: Bug
>Reporter: Hongze Zhang
>Assignee: Hongze Zhang
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.20.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> You can reproduce the bug by running following test case from UdtTest.java:
> {code:java}
> @Test public void testUdt2() {
> final String sql = "select CAST(null AS \"adhoc\".mytype2) as ld "
> + "from (VALUES ROW(1, 'SameName')) AS \"t\" (\"id\", \"desc\")";
> withUdt().query(sql).returns("LD=null\n");
> }
> {code}
> Error thrown:
> {code}
> java.sql.SQLException: Error while executing SQL "select CAST(null AS
> "adhoc".mytype2) as ld from (VALUES ROW(1, 'SameName')) AS "t" ("id",
> "desc")": null
> at org.apache.calcite.avatica.Helper.createException(Helper.java:56)
> at org.apache.calcite.avatica.Helper.createException(Helper.java:41)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:163)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeQuery(AvaticaStatement.java:227)
> at
> org.apache.calcite.test.CalciteAssert.assertQuery(CalciteAssert.java:522)
> at
> org.apache.calcite.test.CalciteAssert$AssertQuery.lambda$returns$1(CalciteAssert.java:1440)
> at
> org.apache.calcite.test.CalciteAssert$AssertQuery.withConnection(CalciteAssert.java:1372)
> at
> org.apache.calcite.test.CalciteAssert$AssertQuery.returns(CalciteAssert.java:1438)
> at
> org.apache.calcite.test.CalciteAssert$AssertQuery.returns(CalciteAssert.java:1421)
> at
> org.apache.calcite.test.CalciteAssert$AssertQuery.returns(CalciteAssert.java:1384)
> at org.apache.calcite.test.UdtTest.testUdt2(UdtTest.java:65)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
> at
> com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:47)
> at
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
> at
> com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)
> Suppressed: org.apache.calcite.util.TestUtil$ExtraInformation: With
> materializationsEnabled=false, limit=0
> at org.apache.calcite.util.TestUtil.rethrow(TestUtil.java:268)
> at
> org.apache.calcite.test.CalciteAssert.assertQuery(CalciteAssert.java:554)
> ... 28 more
> Caused by: java.lang.NullPointerException
> at java.base/java.util.Objects.requireNonNull(Objects.java:221)
> at
>
[jira] [Commented] (CALCITE-2846) Document Oracle-specific functions, such as NVL and LTRIM, in the SQL reference
[ https://issues.apache.org/jira/browse/CALCITE-2846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16830986#comment-16830986 ] Hongze Zhang commented on CALCITE-2846: --- Thanks [~danny0405]. Can we include the spatial functions in the document changes too? Seems to be a nice addition to have. > Document Oracle-specific functions, such as NVL and LTRIM, in the SQL > reference > --- > > Key: CALCITE-2846 > URL: https://issues.apache.org/jira/browse/CALCITE-2846 > Project: Calcite > Issue Type: Improvement > Components: site >Reporter: Julian Hyde >Assignee: Danny Chan >Priority: Major > Labels: documentation, pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > Document Oracle-specific functions (DECODE, NVL, LTRIM, RTRIM, SUBSTR, > GREATEST, LEAST) in the [SQL > reference|https://calcite.apache.org/docs/reference.html]. > Same goes for MySQL-specific functions (e.g. JSON_TYPE). > I don't think we should have separate lists of Oracle-specific functions and > MySQL-specific functions. Because quite a few functions appear in more than > one place. Better, I think, to have a concise annotation against each > function which tables it occurs in. > The current list of tables is standard, oracle, spatial, mysql. Perhaps also > indicate whether a function is an extension to the SQL standard but still > occurs in Calcite's default table. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CALCITE-3045) NullPointerException when casting null literal to composite user defined type
[
https://issues.apache.org/jira/browse/CALCITE-3045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hongze Zhang updated CALCITE-3045:
--
Summary: NullPointerException when casting null literal to composite user
defined type (was: NullPointerException when casting null literal to user
defined type)
> NullPointerException when casting null literal to composite user defined type
> -
>
> Key: CALCITE-3045
> URL: https://issues.apache.org/jira/browse/CALCITE-3045
> Project: Calcite
> Issue Type: Bug
>Reporter: Hongze Zhang
>Priority: Major
> Fix For: 1.20.0
>
>
> You can reproduce the bug by running following test case from UdtTest.java:
> {code:java}
> @Test public void testUdt2() {
> final String sql = "select CAST(null AS \"adhoc\".mytype2) as ld "
> + "from (VALUES ROW(1, 'SameName')) AS \"t\" (\"id\", \"desc\")";
> withUdt().query(sql).returns("LD=null\n");
> }
> {code}
> Error thrown:
> {code}
> java.sql.SQLException: Error while executing SQL "select CAST(null AS
> "adhoc".mytype2) as ld from (VALUES ROW(1, 'SameName')) AS "t" ("id",
> "desc")": null
> at org.apache.calcite.avatica.Helper.createException(Helper.java:56)
> at org.apache.calcite.avatica.Helper.createException(Helper.java:41)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:163)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeQuery(AvaticaStatement.java:227)
> at
> org.apache.calcite.test.CalciteAssert.assertQuery(CalciteAssert.java:522)
> at
> org.apache.calcite.test.CalciteAssert$AssertQuery.lambda$returns$1(CalciteAssert.java:1440)
> at
> org.apache.calcite.test.CalciteAssert$AssertQuery.withConnection(CalciteAssert.java:1372)
> at
> org.apache.calcite.test.CalciteAssert$AssertQuery.returns(CalciteAssert.java:1438)
> at
> org.apache.calcite.test.CalciteAssert$AssertQuery.returns(CalciteAssert.java:1421)
> at
> org.apache.calcite.test.CalciteAssert$AssertQuery.returns(CalciteAssert.java:1384)
> at org.apache.calcite.test.UdtTest.testUdt2(UdtTest.java:65)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
> at
> com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:47)
> at
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
> at
> com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)
> Suppressed: org.apache.calcite.util.TestUtil$ExtraInformation: With
> materializationsEnabled=false, limit=0
> at org.apache.calcite.util.TestUtil.rethrow(TestUtil.java:268)
> at
> org.apache.calcite.test.CalciteAssert.assertQuery(CalciteAssert.java:554)
> ... 28 more
> Caused by: java.lang.NullPointerException
> at java.base/java.util.Objects.requireNonNull(Objects.java:221)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.setValidatedNodeType(SqlValidatorImpl.java:1616)
> at
> org.apache.calcite.sql2rel.StandardConvertletTable.convertCast(StandardConvertletTable.java:532)
> at
>
[jira] [Comment Edited] (CALCITE-3045) NullPointerException when casting null literal to user defined type
[
https://issues.apache.org/jira/browse/CALCITE-3045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16830904#comment-16830904
]
Hongze Zhang edited comment on CALCITE-3045 at 5/1/19 8:01 AM:
---
It seems the issue is somehow related to CALCITE-2402 fix, in which we changed
some codes converting calls of cast function in
{{StandardConvertletTable.java}}.
IMHO this requires just some minor follow-up changes, so let's see if we can
bring the fix to 1.20.0.
was (Author: zhztheplayer):
It seems the issue is somehow related to CALCITE-2402 fix, in which we changed
some codes converting calls of cast function from
{{StandardConvertletTable.java}}.
IMHO this requires just some minor follow-up changes, so let's see if we can
bring the fix to 1.20.0.
> NullPointerException when casting null literal to user defined type
> ---
>
> Key: CALCITE-3045
> URL: https://issues.apache.org/jira/browse/CALCITE-3045
> Project: Calcite
> Issue Type: Bug
>Reporter: Hongze Zhang
>Priority: Major
> Fix For: 1.20.0
>
>
> You can reproduce the bug by running following test case from UdtTest.java:
> {code:java}
> @Test public void testUdt2() {
> final String sql = "select CAST(null AS \"adhoc\".mytype2) as ld "
> + "from (VALUES ROW(1, 'SameName')) AS \"t\" (\"id\", \"desc\")";
> withUdt().query(sql).returns("LD=null\n");
> }
> {code}
> Error thrown:
> {code}
> java.sql.SQLException: Error while executing SQL "select CAST(null AS
> "adhoc".mytype2) as ld from (VALUES ROW(1, 'SameName')) AS "t" ("id",
> "desc")": null
> at org.apache.calcite.avatica.Helper.createException(Helper.java:56)
> at org.apache.calcite.avatica.Helper.createException(Helper.java:41)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:163)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeQuery(AvaticaStatement.java:227)
> at
> org.apache.calcite.test.CalciteAssert.assertQuery(CalciteAssert.java:522)
> at
> org.apache.calcite.test.CalciteAssert$AssertQuery.lambda$returns$1(CalciteAssert.java:1440)
> at
> org.apache.calcite.test.CalciteAssert$AssertQuery.withConnection(CalciteAssert.java:1372)
> at
> org.apache.calcite.test.CalciteAssert$AssertQuery.returns(CalciteAssert.java:1438)
> at
> org.apache.calcite.test.CalciteAssert$AssertQuery.returns(CalciteAssert.java:1421)
> at
> org.apache.calcite.test.CalciteAssert$AssertQuery.returns(CalciteAssert.java:1384)
> at org.apache.calcite.test.UdtTest.testUdt2(UdtTest.java:65)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
> at
> com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:47)
> at
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
> at
> com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)
> Suppressed: org.apache.calcite.util.TestUtil$ExtraInformation: With
> materializationsEnabled=false, limit=0
> at org.apache.calcite.util.TestUtil.rethrow(TestUtil.java:268)
> at
>
[jira] [Comment Edited] (CALCITE-3045) NullPointerException when casting null literal to user defined type
[
https://issues.apache.org/jira/browse/CALCITE-3045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16830904#comment-16830904
]
Hongze Zhang edited comment on CALCITE-3045 at 5/1/19 7:59 AM:
---
It seems the issue is somehow related to CALCITE-2402 fix, in which we changed
some codes converting calls of cast function from
{{StandardConvertletTable.java}}.
IMHO this requires just some minor follow-up changes, so let's see if we can
bring the fix to 1.20.0.
was (Author: zhztheplayer):
It seems the issue is somehow related to CALCITE-2402 fix, in which we changed
some codes converting calls of cast function.
IMHO this requires just some minor follow-up changes, so let's see if we can
bring the fix to 1.20.0.
> NullPointerException when casting null literal to user defined type
> ---
>
> Key: CALCITE-3045
> URL: https://issues.apache.org/jira/browse/CALCITE-3045
> Project: Calcite
> Issue Type: Bug
>Reporter: Hongze Zhang
>Priority: Major
> Fix For: 1.20.0
>
>
> You can reproduce the bug by running following test case from UdtTest.java:
> {code:java}
> @Test public void testUdt2() {
> final String sql = "select CAST(null AS \"adhoc\".mytype2) as ld "
> + "from (VALUES ROW(1, 'SameName')) AS \"t\" (\"id\", \"desc\")";
> withUdt().query(sql).returns("LD=null\n");
> }
> {code}
> Error thrown:
> {code}
> java.sql.SQLException: Error while executing SQL "select CAST(null AS
> "adhoc".mytype2) as ld from (VALUES ROW(1, 'SameName')) AS "t" ("id",
> "desc")": null
> at org.apache.calcite.avatica.Helper.createException(Helper.java:56)
> at org.apache.calcite.avatica.Helper.createException(Helper.java:41)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:163)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeQuery(AvaticaStatement.java:227)
> at
> org.apache.calcite.test.CalciteAssert.assertQuery(CalciteAssert.java:522)
> at
> org.apache.calcite.test.CalciteAssert$AssertQuery.lambda$returns$1(CalciteAssert.java:1440)
> at
> org.apache.calcite.test.CalciteAssert$AssertQuery.withConnection(CalciteAssert.java:1372)
> at
> org.apache.calcite.test.CalciteAssert$AssertQuery.returns(CalciteAssert.java:1438)
> at
> org.apache.calcite.test.CalciteAssert$AssertQuery.returns(CalciteAssert.java:1421)
> at
> org.apache.calcite.test.CalciteAssert$AssertQuery.returns(CalciteAssert.java:1384)
> at org.apache.calcite.test.UdtTest.testUdt2(UdtTest.java:65)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
> at
> com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:47)
> at
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
> at
> com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)
> Suppressed: org.apache.calcite.util.TestUtil$ExtraInformation: With
> materializationsEnabled=false, limit=0
> at org.apache.calcite.util.TestUtil.rethrow(TestUtil.java:268)
> at
>
[jira] [Updated] (CALCITE-3045) NullPointerException when casting null literal to user defined type
[
https://issues.apache.org/jira/browse/CALCITE-3045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hongze Zhang updated CALCITE-3045:
--
Description:
You can reproduce the bug by running following test case from UdtTest.java:
{code:java}
@Test public void testUdt2() {
final String sql = "select CAST(null AS \"adhoc\".mytype2) as ld "
+ "from (VALUES ROW(1, 'SameName')) AS \"t\" (\"id\", \"desc\")";
withUdt().query(sql).returns("LD=null\n");
}
{code}
Error thrown:
{code}
java.sql.SQLException: Error while executing SQL "select CAST(null AS
"adhoc".mytype2) as ld from (VALUES ROW(1, 'SameName')) AS "t" ("id", "desc")":
null
at org.apache.calcite.avatica.Helper.createException(Helper.java:56)
at org.apache.calcite.avatica.Helper.createException(Helper.java:41)
at
org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:163)
at
org.apache.calcite.avatica.AvaticaStatement.executeQuery(AvaticaStatement.java:227)
at
org.apache.calcite.test.CalciteAssert.assertQuery(CalciteAssert.java:522)
at
org.apache.calcite.test.CalciteAssert$AssertQuery.lambda$returns$1(CalciteAssert.java:1440)
at
org.apache.calcite.test.CalciteAssert$AssertQuery.withConnection(CalciteAssert.java:1372)
at
org.apache.calcite.test.CalciteAssert$AssertQuery.returns(CalciteAssert.java:1438)
at
org.apache.calcite.test.CalciteAssert$AssertQuery.returns(CalciteAssert.java:1421)
at
org.apache.calcite.test.CalciteAssert$AssertQuery.returns(CalciteAssert.java:1384)
at org.apache.calcite.test.UdtTest.testUdt2(UdtTest.java:65)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
at
com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
at
com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:47)
at
com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
at
com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)
Suppressed: org.apache.calcite.util.TestUtil$ExtraInformation: With
materializationsEnabled=false, limit=0
at org.apache.calcite.util.TestUtil.rethrow(TestUtil.java:268)
at
org.apache.calcite.test.CalciteAssert.assertQuery(CalciteAssert.java:554)
... 28 more
Caused by: java.lang.NullPointerException
at java.base/java.util.Objects.requireNonNull(Objects.java:221)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.setValidatedNodeType(SqlValidatorImpl.java:1616)
at
org.apache.calcite.sql2rel.StandardConvertletTable.convertCast(StandardConvertletTable.java:532)
at
org.apache.calcite.sql2rel.SqlNodeToRexConverterImpl.convertCall(SqlNodeToRexConverterImpl.java:63)
at
org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.visit(SqlToRelConverter.java:4758)
at
org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.visit(SqlToRelConverter.java:4063)
at org.apache.calcite.sql.SqlCall.accept(SqlCall.java:139)
at
org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.convertExpression(SqlToRelConverter.java:4627)
at
org.apache.calcite.sql2rel.StandardConvertletTable.lambda$new$9(StandardConvertletTable.java:208)
at
[jira] [Commented] (CALCITE-3045) NullPointerException when casting null literal to user defined type
[
https://issues.apache.org/jira/browse/CALCITE-3045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16830904#comment-16830904
]
Hongze Zhang commented on CALCITE-3045:
---
It seems the issue is somehow related to CALCITE-2402 fix, in which we changed
some codes converting calls of cast function.
IMHO this requires just some minor follow-up changes, so let's see if we can
bring the fix to 1.20.0.
> NullPointerException when casting null literal to user defined type
> ---
>
> Key: CALCITE-3045
> URL: https://issues.apache.org/jira/browse/CALCITE-3045
> Project: Calcite
> Issue Type: Bug
>Reporter: Hongze Zhang
>Priority: Major
> Fix For: 1.20.0
>
>
> You can reproduce the bug by running following test case from UdtTest.java:
> {code:java}
> @Test public void testUdt2() {
> final String sql = "select CAST(null AS \"adhoc\".mytype2) as ld "
> + "from (VALUES ROW(1, 'SameName')) AS \"t\" (\"id\", \"desc\")";
> withUdt().query(sql).returns("LD=1\n");
> }
> {code}
> Error thrown:
> {code}
> java.sql.SQLException: Error while executing SQL "select CAST(null AS
> "adhoc".mytype2) as ld from (VALUES ROW(1, 'SameName')) AS "t" ("id",
> "desc")": null
> at org.apache.calcite.avatica.Helper.createException(Helper.java:56)
> at org.apache.calcite.avatica.Helper.createException(Helper.java:41)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:163)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeQuery(AvaticaStatement.java:227)
> at
> org.apache.calcite.test.CalciteAssert.assertQuery(CalciteAssert.java:522)
> at
> org.apache.calcite.test.CalciteAssert$AssertQuery.lambda$returns$1(CalciteAssert.java:1440)
> at
> org.apache.calcite.test.CalciteAssert$AssertQuery.withConnection(CalciteAssert.java:1372)
> at
> org.apache.calcite.test.CalciteAssert$AssertQuery.returns(CalciteAssert.java:1438)
> at
> org.apache.calcite.test.CalciteAssert$AssertQuery.returns(CalciteAssert.java:1421)
> at
> org.apache.calcite.test.CalciteAssert$AssertQuery.returns(CalciteAssert.java:1384)
> at org.apache.calcite.test.UdtTest.testUdt2(UdtTest.java:65)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
> at
> com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:47)
> at
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
> at
> com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)
> Suppressed: org.apache.calcite.util.TestUtil$ExtraInformation: With
> materializationsEnabled=false, limit=0
> at org.apache.calcite.util.TestUtil.rethrow(TestUtil.java:268)
> at
> org.apache.calcite.test.CalciteAssert.assertQuery(CalciteAssert.java:554)
> ... 28 more
> Caused by: java.lang.NullPointerException
> at java.base/java.util.Objects.requireNonNull(Objects.java:221)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.setValidatedNodeType(SqlValidatorImpl.java:1616)
> at
>
[jira] [Created] (CALCITE-3045) NullPointerException when casting null literal to user defined type
Hongze Zhang created CALCITE-3045:
-
Summary: NullPointerException when casting null literal to user
defined type
Key: CALCITE-3045
URL: https://issues.apache.org/jira/browse/CALCITE-3045
Project: Calcite
Issue Type: Bug
Reporter: Hongze Zhang
Fix For: 1.20.0
You can reproduce the bug by running following test case from UdtTest.java:
{code:java}
@Test public void testUdt2() {
final String sql = "select CAST(null AS \"adhoc\".mytype2) as ld "
+ "from (VALUES ROW(1, 'SameName')) AS \"t\" (\"id\", \"desc\")";
withUdt().query(sql).returns("LD=1\n");
}
{code}
Error thrown:
{code}
java.sql.SQLException: Error while executing SQL "select CAST(null AS
"adhoc".mytype2) as ld from (VALUES ROW(1, 'SameName')) AS "t" ("id", "desc")":
null
at org.apache.calcite.avatica.Helper.createException(Helper.java:56)
at org.apache.calcite.avatica.Helper.createException(Helper.java:41)
at
org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:163)
at
org.apache.calcite.avatica.AvaticaStatement.executeQuery(AvaticaStatement.java:227)
at
org.apache.calcite.test.CalciteAssert.assertQuery(CalciteAssert.java:522)
at
org.apache.calcite.test.CalciteAssert$AssertQuery.lambda$returns$1(CalciteAssert.java:1440)
at
org.apache.calcite.test.CalciteAssert$AssertQuery.withConnection(CalciteAssert.java:1372)
at
org.apache.calcite.test.CalciteAssert$AssertQuery.returns(CalciteAssert.java:1438)
at
org.apache.calcite.test.CalciteAssert$AssertQuery.returns(CalciteAssert.java:1421)
at
org.apache.calcite.test.CalciteAssert$AssertQuery.returns(CalciteAssert.java:1384)
at org.apache.calcite.test.UdtTest.testUdt2(UdtTest.java:65)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
at
com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
at
com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:47)
at
com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
at
com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)
Suppressed: org.apache.calcite.util.TestUtil$ExtraInformation: With
materializationsEnabled=false, limit=0
at org.apache.calcite.util.TestUtil.rethrow(TestUtil.java:268)
at
org.apache.calcite.test.CalciteAssert.assertQuery(CalciteAssert.java:554)
... 28 more
Caused by: java.lang.NullPointerException
at java.base/java.util.Objects.requireNonNull(Objects.java:221)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.setValidatedNodeType(SqlValidatorImpl.java:1616)
at
org.apache.calcite.sql2rel.StandardConvertletTable.convertCast(StandardConvertletTable.java:532)
at
org.apache.calcite.sql2rel.SqlNodeToRexConverterImpl.convertCall(SqlNodeToRexConverterImpl.java:63)
at
org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.visit(SqlToRelConverter.java:4758)
at
org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.visit(SqlToRelConverter.java:4063)
at org.apache.calcite.sql.SqlCall.accept(SqlCall.java:139)
at
org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.convertExpression(SqlToRelConverter.java:4627)
at
[jira] [Resolved] (CALCITE-3029) Java-oriented field type is wrongly forced to be NOT NULL after being converted to SQL-oriented
[
https://issues.apache.org/jira/browse/CALCITE-3029?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hongze Zhang resolved CALCITE-3029.
---
Resolution: Fixed
Fixed in
[37002c1399cea1464b5d53c0fc4e5ec90f831f1b|https://gitbox.apache.org/repos/asf?p=calcite.git;a=commit;h=37002c1399cea1464b5d53c0fc4e5ec90f831f1b].
Thanks for the review, [~rubenql], [~zabetak], [~danny0405]!
> Java-oriented field type is wrongly forced to be NOT NULL after being
> converted to SQL-oriented
> ---
>
> Key: CALCITE-3029
> URL: https://issues.apache.org/jira/browse/CALCITE-3029
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.19.0
>Reporter: Hongze Zhang
>Assignee: Hongze Zhang
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.20.0
>
> Time Spent: 2h 10m
> Remaining Estimate: 0h
>
> A Java-oriented field type loses its nullable constraint after calling method
> {{org.apache.calcite.jdbc.JavaTypeFactoryImpl#toSql(org.apache.calcite.rel.type.RelDataType)}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CALCITE-3039) In Interpreter, min() incorrectly returns maximum double value
[
https://issues.apache.org/jira/browse/CALCITE-3039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hongze Zhang updated CALCITE-3039:
--
Summary: In Interpreter, min() incorrectly returns maximum double value
(was: In interpreter, min() incorrectly returns maximum double value)
> In Interpreter, min() incorrectly returns maximum double value
> --
>
> Key: CALCITE-3039
> URL: https://issues.apache.org/jira/browse/CALCITE-3039
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.17.0
>Reporter: dijkspicy
>Priority: Major
> Labels: easyfix, pull-request-available
> Time Spent: 20m
> Remaining Estimate: 0h
>
> {code:java}
> //代码占位符
> /** Implementation of {@code MIN} function to calculate the minimum of
> * {@code float} values as a user-defined aggregate.
> */
> public static class MinFloat extends NumericComparison {
> public MinFloat() {
> super(Float.MAX_VALUE, Math::min);
> }
> }
> /** Implementation of {@code MIN} function to calculate the minimum of
> * {@code double} and {@code real} values as a user-defined aggregate.
> */
> public static class MinDouble extends NumericComparison {
> public MinDouble() {
> super(Double.MAX_VALUE, Math::max);
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (CALCITE-3039) In interpreter, min() incorrectly returns maximum double value
[
https://issues.apache.org/jira/browse/CALCITE-3039?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16829932#comment-16829932
]
Hongze Zhang edited comment on CALCITE-3039 at 4/30/19 4:04 AM:
[~dijkspicy] - Thanks for reporting this! And it looks like a bug. Feel free to
file PR if you would like to help with fixing.
was (Author: zhztheplayer):
[~dijkspicy] - Thanks for reporting this! and it looks like a bug. Feel free to
file PR if you would like to help with fixing.
> In interpreter, min() incorrectly returns maximum double value
> --
>
> Key: CALCITE-3039
> URL: https://issues.apache.org/jira/browse/CALCITE-3039
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.17.0
>Reporter: dijkspicy
>Priority: Major
> Labels: easyfix
>
> {code:java}
> //代码占位符
> /** Implementation of {@code MIN} function to calculate the minimum of
> * {@code float} values as a user-defined aggregate.
> */
> public static class MinFloat extends NumericComparison {
> public MinFloat() {
> super(Float.MAX_VALUE, Math::min);
> }
> }
> /** Implementation of {@code MIN} function to calculate the minimum of
> * {@code double} and {@code real} values as a user-defined aggregate.
> */
> public static class MinDouble extends NumericComparison {
> public MinDouble() {
> super(Double.MAX_VALUE, Math::max);
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-3039) In interpreter, min() incorrectly returns maximum double value
[
https://issues.apache.org/jira/browse/CALCITE-3039?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16829932#comment-16829932
]
Hongze Zhang commented on CALCITE-3039:
---
[~dijkspicy] - Thanks for reporting this! and it looks like a bug. Feel free to
file PR if you would like to help with fixing.
> In interpreter, min() incorrectly returns maximum double value
> --
>
> Key: CALCITE-3039
> URL: https://issues.apache.org/jira/browse/CALCITE-3039
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.17.0
>Reporter: dijkspicy
>Priority: Major
> Labels: easyfix
>
> {code:java}
> //代码占位符
> /** Implementation of {@code MIN} function to calculate the minimum of
> * {@code float} values as a user-defined aggregate.
> */
> public static class MinFloat extends NumericComparison {
> public MinFloat() {
> super(Float.MAX_VALUE, Math::min);
> }
> }
> /** Implementation of {@code MIN} function to calculate the minimum of
> * {@code double} and {@code real} values as a user-defined aggregate.
> */
> public static class MinDouble extends NumericComparison {
> public MinDouble() {
> super(Double.MAX_VALUE, Math::max);
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CALCITE-3039) In interpreter, min() incorrectly returns maximum double value
[
https://issues.apache.org/jira/browse/CALCITE-3039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hongze Zhang updated CALCITE-3039:
--
Summary: In interpreter, min() incorrectly returns maximum double value
(was: Why MinFloat use Math::min while MinDouble use Math::max as its
comparision in AggragateNode ?)
> In interpreter, min() incorrectly returns maximum double value
> --
>
> Key: CALCITE-3039
> URL: https://issues.apache.org/jira/browse/CALCITE-3039
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.17.0
>Reporter: dijkspicy
>Priority: Major
> Labels: easyfix
>
> {code:java}
> //代码占位符
> /** Implementation of {@code MIN} function to calculate the minimum of
> * {@code float} values as a user-defined aggregate.
> */
> public static class MinFloat extends NumericComparison {
> public MinFloat() {
> super(Float.MAX_VALUE, Math::min);
> }
> }
> /** Implementation of {@code MIN} function to calculate the minimum of
> * {@code double} and {@code real} values as a user-defined aggregate.
> */
> public static class MinDouble extends NumericComparison {
> public MinDouble() {
> super(Double.MAX_VALUE, Math::max);
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-3029) Java-oriented field type is wrongly forced to be NOT NULL after being converted to SQL-oriented
[
https://issues.apache.org/jira/browse/CALCITE-3029?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16829913#comment-16829913
]
Hongze Zhang commented on CALCITE-3029:
---
I've updated the PR accordingly.
> Java-oriented field type is wrongly forced to be NOT NULL after being
> converted to SQL-oriented
> ---
>
> Key: CALCITE-3029
> URL: https://issues.apache.org/jira/browse/CALCITE-3029
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.19.0
>Reporter: Hongze Zhang
>Assignee: Hongze Zhang
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.20.0
>
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> A Java-oriented field type loses its nullable constraint after calling method
> {{org.apache.calcite.jdbc.JavaTypeFactoryImpl#toSql(org.apache.calcite.rel.type.RelDataType)}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (CALCITE-1207) Allow numeric connection properties, and 'K', 'M', 'G' suffixes
[ https://issues.apache.org/jira/browse/CALCITE-1207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hongze Zhang closed CALCITE-1207. - The issue was resolved but not closed in the given fix version. Closing now. > Allow numeric connection properties, and 'K', 'M', 'G' suffixes > --- > > Key: CALCITE-1207 > URL: https://issues.apache.org/jira/browse/CALCITE-1207 > Project: Calcite > Issue Type: Bug >Reporter: Julian Hyde >Assignee: Julian Hyde >Priority: Major > Fix For: avatica-1.8.0 > > > Allow numeric connection properties. These means adding NUMBER to enum > ConnectionProperty.Type, and getInt, getLong and getDouble methods to > ConnectionConfigImpl.PropEnv. > If a numeric property has a value "10k" interpret it as 10 * 1024. The "k" or > "K" suffix means 1024 multiplier, similarly "m" or "M" (1024 * 1024), "g" or > "G" (1024 * 1024 * 1024). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (CALCITE-1128) Support addBatch()/executeBatch() in remote driver
[ https://issues.apache.org/jira/browse/CALCITE-1128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hongze Zhang closed CALCITE-1128. - The issue was resolved but not closed in the given fix version. Closing now. > Support addBatch()/executeBatch() in remote driver > -- > > Key: CALCITE-1128 > URL: https://issues.apache.org/jira/browse/CALCITE-1128 > Project: Calcite > Issue Type: Improvement > Components: avatica >Reporter: Josh Elser >Assignee: Josh Elser >Priority: Critical > Fix For: avatica-1.8.0 > > > JDBC has some "batch-oriented" APIs which should help in the heavy-write > workloads. These should help ammortize the RPC cost of repeated > PrepareAndExecuteRequests and ExecuteRequests. > Through some of the recent performance work, CALCITE-1091, I think we're > getting close to the limit of what is possible given our current server > implementation (both in terms of HTTP-based clients and deserialization in > POJOs). The thought is that we will get some better throughput if we reduce > the total number of RPCs. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (CALCITE-109) Add JDBC options so that you can connect to MongoDB without a model file
[ https://issues.apache.org/jira/browse/CALCITE-109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hongze Zhang closed CALCITE-109. The issue was resolved but not closed in the given fix version. Closing now. > Add JDBC options so that you can connect to MongoDB without a model file > > > Key: CALCITE-109 > URL: https://issues.apache.org/jira/browse/CALCITE-109 > Project: Calcite > Issue Type: Bug >Reporter: GitHub Import >Priority: Major > Labels: github-import > Fix For: 1.8.0 > > > Add JDBC options so that you can connect to MongoDB without a model file. > Something like this: > ``` > jdbc:optiq:adapter=mongodb;url=mongodb://localhost/databasename > ``` > Imported from GitHub > Url: https://github.com/julianhyde/optiq/issues/109 > Created by: [julianhyde|https://github.com/julianhyde] > Labels: > Created at: Mon Dec 30 19:28:01 CET 2013 > State: open -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (CALCITE-643) User authentication for avatica clients
[ https://issues.apache.org/jira/browse/CALCITE-643?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hongze Zhang closed CALCITE-643. The issue was resolved but not closed in the given fix version. Closing now. > User authentication for avatica clients > --- > > Key: CALCITE-643 > URL: https://issues.apache.org/jira/browse/CALCITE-643 > Project: Calcite > Issue Type: Improvement > Components: avatica >Reporter: Nick Dimiduk >Assignee: Josh Elser >Priority: Major > Labels: avatica > Fix For: avatica-1.8.0 > > > Avatica client API needs a means for accepting a users authorization status, > passing it to the server, and the server to act on that users behalf when > interacting with the underlying connection. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (CALCITE-1189) Unit test failure when JVM default charset is not UTF-8
[ https://issues.apache.org/jira/browse/CALCITE-1189?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hongze Zhang closed CALCITE-1189. - The issue was resolved but not closed in the given fix version. Closing now. > Unit test failure when JVM default charset is not UTF-8 > --- > > Key: CALCITE-1189 > URL: https://issues.apache.org/jira/browse/CALCITE-1189 > Project: Calcite > Issue Type: Bug > Components: avatica >Reporter: Josh Elser >Assignee: Josh Elser >Priority: Trivial > Fix For: avatica-1.8.0 > > > The changes done in CALCITE-1103 (potentially along with the new test for > unicode column names in CALCITE-835) was causing failures on some ASF jenkins > hosts. > In TypedValue, when serializing a String in a the Protobuf variant of > TypedValue, the resulting bytes were platform dependent, instead of always > specifying UTF-8. Protobuf requires UTF-8 bytes for the method we were > invoking, and, thus, threw an exception. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (CALCITE-1251) Write release notes
[ https://issues.apache.org/jira/browse/CALCITE-1251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hongze Zhang closed CALCITE-1251. - The issue was resolved but not closed in the given fix version. Closing now. > Write release notes > --- > > Key: CALCITE-1251 > URL: https://issues.apache.org/jira/browse/CALCITE-1251 > Project: Calcite > Issue Type: Sub-task > Components: avatica >Reporter: Josh Elser >Assignee: Josh Elser >Priority: Major > Fix For: avatica-1.8.0 > > > Forgot that I need to write up release notes before I make an rc0 because the > site is also contained in the tag. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (CALCITE-1267) Point to release notes on website in README
[ https://issues.apache.org/jira/browse/CALCITE-1267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hongze Zhang closed CALCITE-1267. - The issue was resolved but not closed in the given fix version. Closing now. > Point to release notes on website in README > --- > > Key: CALCITE-1267 > URL: https://issues.apache.org/jira/browse/CALCITE-1267 > Project: Calcite > Issue Type: Task > Components: avatica, site >Reporter: Josh Elser >Assignee: Josh Elser >Priority: Trivial > Fix For: avatica-1.8.0 > > > bq. In my opinion, it would be nice if there were a README file saying "you > have downloaded avatica version 1.8; the release notes are in file xxx". But > by no means a show-stopper. > We can easily point to the website in the README. Pretty trivial to do. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (CALCITE-1193) NullPointerException when trying to execute prepared statement using avatica
[
https://issues.apache.org/jira/browse/CALCITE-1193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hongze Zhang closed CALCITE-1193.
-
The issue was resolved but not closed in the given fix version. Closing now.
> NullPointerException when trying to execute prepared statement using avatica
>
>
> Key: CALCITE-1193
> URL: https://issues.apache.org/jira/browse/CALCITE-1193
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Affects Versions: avatica-1.7.1
> Environment: Phoenix 4.7.0 and Phoenix 4.8.0-SNAPSHOT
>Reporter: Francis Chuang
>Assignee: Josh Elser
>Priority: Major
> Fix For: avatica-1.8.0
>
>
> To reproduce, set the phoenix query server to use JSON for serialization:
> 1. Create a table called {{my_table}} and seed it using SquirrelSQL:
> {code}
> CREATE TABLE my_table (k BIGINT PRIMARY KEY, v VARCHAR) TRANSACTIONAL=true
> UPSERT INTO my_table VALUES (1,'A')
> UPSERT INTO my_table VALUES (2,'B')
> UPSERT INTO my_table VALUES (3,'C')
> UPSERT INTO my_table VALUES (4,'D')
> {code}
> Send the following requests using curl:
> {code}
> C:\Users\user
> λ curl localhost:8765 -XPOST --data '{"request":
> "openConnection","connectionId": "my-conn"}'
> {"response":"openConnection","rpcMetadata":{"response":"rpcMetadata","serverAddress":"f826338-phoenix-server.f826338:8765"}}
> C:\Users\user
> λ curl localhost:8765 -XPOST --data '{"request": "prepare","connectionId":
> "my-conn","sql": "SELECT * FROM my_table","maxRowCount": 1}'
> {"response":"prepare","statement":{"connectionId":"my-conn","id":36,"signature":{"columns":[{"ordinal":0,"autoIncrement":false,"caseSensitive":false,"searchable":true,"currency":false,"nullable":0,"signed":true,"displaySize":40,"label":"K","columnName":"K","schemaName":"","precision":0,"scale":0,"tableName":"MY_TABLE","catalogName":"","type":{"type":"scalar","id":-5,"name":"BIGINT","rep":"PRIMITIVE_LONG"},"readOnly":true,"writable":false,"definitelyWritable":false,"columnClassName":"java.lang.Long"},{"ordinal":1,"autoIncrement":false,"caseSensitive":false,"searchable":true,"currency":false,"nullable":1,"signed":false,"displaySize":40,"label":"V","columnName":"V","schemaName":"","precision":0,"scale":0,"tableName":"MY_TABLE","catalogName":"","type":{"type":"scalar","id":12,"name":"VARCHAR","rep":"STRING"},"readOnly":true,"writable":false,"definitelyWritable":false,"columnClassName":"java.lang.String"}],"sql":"SELECT
> * FROM
> my_table","parameters":[],"cursorFactory":{"style":"LIST","clazz":null,"fieldNames":null},"statementType":null}},"rpcMetadata":{"response":"rpcMetadata","serverAddress":"f826338-phoenix-server.f826338:8765"}}
> C:\Users\user
> λ curl localhost:8765 -XPOST --data '{"request": "execute","statementHandle":
> {"connectionId": "my-conn","id": 36},"maxRowCount": 1}'
> {"response":"error","exceptions":["java.lang.NullPointerException\n\tat
> org.apache.calcite.avatica.MetaImpl.checkParameterValueHasNull(MetaImpl.java:952)\n\tat
> org.apache.calcite.avatica.jdbc.JdbcMeta.execute(JdbcMeta.java:781)\n\tat
> org.apache.calcite.avatica.remote.LocalService.apply(LocalService.java:233)\n\tat
>
> org.apache.calcite.avatica.remote.Service$ExecuteRequest.accept(Service.java:950)\n\tat
>
> org.apache.calcite.avatica.remote.Service$ExecuteRequest.accept(Service.java:928)\n\tat
>
> org.apache.calcite.avatica.remote.AbstractHandler.apply(AbstractHandler.java:102)\n\tat
>
> org.apache.calcite.avatica.remote.JsonHandler.apply(JsonHandler.java:43)\n\tat
>
> org.apache.calcite.avatica.server.AvaticaJsonHandler.handle(AvaticaJsonHandler.java:73)\n\tat
>
> org.eclipse.jetty.server.handler.HandlerList.handle(HandlerList.java:52)\n\tat
>
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)\n\tat
> org.eclipse.jetty.server.Server.handle(Server.java:497)\n\tat
> org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:310)\n\tat
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:245)\n\tat
>
> org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:540)\n\tat
>
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)\n\tat
>
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)\n\tat
>
> java.lang.Thread.run(Thread.java:745)\n"],"errorMessage":"NullPointerException:
> (null exception
> message)","errorCode":-1,"sqlState":"0","severity":"UNKNOWN","rpcMetadata":{"response":"rpcMetadata","serverAddress":"f826338-phoenix-server.f826338:8765"}}
> {code}
> Notice that the server throws a NPE when trying to execute the prepared
> statement.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (CALCITE-538) Support skip overwrite in generate-fmpp-sources
[ https://issues.apache.org/jira/browse/CALCITE-538?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hongze Zhang closed CALCITE-538. The issue was resolved but not closed in the given fix version. Closing now. > Support skip overwrite in generate-fmpp-sources > --- > > Key: CALCITE-538 > URL: https://issues.apache.org/jira/browse/CALCITE-538 > Project: Calcite > Issue Type: Sub-task >Reporter: Vladimir Sitnikov >Assignee: Vladimir Sitnikov >Priority: Major > Fix For: 1.0.0-incubating > > > fmpp should not overwrite the destination file if the contents is the same. > Relevant issue is here: https://github.com/freemarker/fmpp/issues/11 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
