[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&focusedCommentId=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] [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&focusedCommentId=17417104#comment-17417104 ] Hongze Zhang edited comment on CALCITE-4785 at 9/18/21, 9:38 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 refactors. Although this kind of check was too not 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. 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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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] [Comment Edited] (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&focusedCommentId=16859110#comment-16859110 ] Hongze Zhang edited comment on CALCITE-2804 at 6/8/19 5:05 AM: --- It is weird. I noticed the quote difference on -MM-dd... 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] was (Author: zhztheplayer): 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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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])
[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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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]):
[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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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-35) Support parenthesized sub-clause in JOIN
[ https://issues.apache.org/jira/browse/CALCITE-35?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16838531#comment-16838531 ] Hongze Zhang commented on CALCITE-35: - I can imagine you have spent quite a few time on this, but if we end up using a syntactic lookahead to deal with the conflict, I am then not pretty sure whether it is a good idea to make such changes to parser at this time. Do you have any suggestions, [~julianhyde]? It seems you had looked into the issue long time ago. > 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-3017) Improve null handling of JsonValueExpressionOperator
[ https://issues.apache.org/jira/browse/CALCITE-3017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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] [Comment Edited] (CALCITE-3017) Improve null handling of JsonValueExpressionOperator
[ https://issues.apache.org/jira/browse/CALCITE-3017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16827655#comment-16827655 ] Hongze Zhang edited comment on CALCITE-3017 at 5/9/19 7:10 AM: --- I am about to finish a patch resolving this (the work is at https://github.com/zhztheplayer/calcite/tree/3017). The main approach is to remove the implicit add of calls to {{JsonValueExpressionOperator}}, and use Java method overload instead. This way a dejsonized NULL can be wrapped and represent by a {{JsonValueContext}} object. A downside of removing implicit calls is that users should implement the implicit behavior by themselves. In a sense this is not quite a bad thing because: * It reduces complexity; * "Implicit" behavior is reasonable to be considered in a lower level/layer. Also, some minor refactors/changes done: * Remove {{JsonApiCommonSyntaxOperator}}, the reason to do this is similar: complexity reduced, and more flexibility gained; * Move JSON processing functions out from {{SqlFunctions}}, create new one named {{JsonFunctions}}; * Rex2Lix: Add explicit cast to Java type for null literal, to avoid error on calling overloaded methods. was (Author: zhztheplayer): I am about to finished a patch resolving this (the work is at https://github.com/zhztheplayer/calcite/tree/3017). The main approach is to remove the implicit add of calls to {{JsonValueExpressionOperator}}, and use Java method overload instead. This way a dejsonized NULL can be wrapped and represent by a {{JsonValueContext}} object. A downside of removing implicit calls is that users should implement the implicit behavior by themselves. In a sense this is not quite a bad thing because: * It reduces complexity; * "Implicit" behavior is reasonable to be considered in a lower level/layer. Also, some minor refactors/changes done: * Remove {{JsonApiCommonSyntaxOperator}}, the reason to do this is similar: complexity reduced, and more flexibility gained; * Move JSON processing functions out from {{SqlFunctions}}, create new one named {{JsonFunctions}}; * Rex2Lix: Add explicit cast to Java type for null literal, to avoid error on calling overloaded methods. > Improve null handling of JsonValueExpressionOperator > > > Key: CALCITE-3017 > URL: https://issues.apache.org/jira/browse/CALCITE-3017 > Project: Calcite > Issue Type: Sub-task >Reporter: Hongze Zhang >Assignee: Hongze Zhang >Priority: Major > Labels: pull-request-available > Fix For: 1.20.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > In Calcite's implementation, {{JsonValueExpressionOperator}} currently > returns a null value no matter the argument is JSON NULL value or SQL NULL > value. But in MySQL, some JSON functions behave differently on different null > inputs. For instance for a MySQL JSON function {{JSON_STORAGE_SIZE}}, if we > execute: > {code:sql} > SELECT JSON_STORAGE_SIZE(null), JSON_STORAGE_SIZE('null') > {code} > The result should be: > ||JSON_STORAGE_SIZE(null)||JSON_STORAGE_SIZE('null')|| > |null|2| > We should improve the operator a bit to support different behaviors. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[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 > org.codehaus.janino.UnitCompiler$16.visitMethodInvocation(UnitCompiler.java:4396
[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&focusedCommentId=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) >
[jira] [Commented] (CALCITE-3051) Babel parser should parse special table expressions
[ https://issues.apache.org/jira/browse/CALCITE-3051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16834717#comment-16834717 ] Hongze Zhang commented on CALCITE-3051: --- Thanks Muhammad. I think there is a similar issue CALCITE-35 which seems not that easy to solve. Could you please check if they are related? By the way, if I didn't get it wrong, per std the syntax is called "". > Babel parser should parse special table expressions > --- > > Key: CALCITE-3051 > URL: https://issues.apache.org/jira/browse/CALCITE-3051 > Project: Calcite > Issue Type: Improvement > Components: babel >Affects Versions: 1.19.0 >Reporter: Muhammad Gelbana >Priority: Major > Labels: postgresql > > PostgreSQL query > {code:sql} > SELECT * FROM " > ( > ( > (S.C c INNER JOIN S.N n ON n.id = c.id) > INNER JOIN S.A a ON (NOT a.isactive) > ) INNER JOIN S.T t ON t.id = a.id > ) > {code} > Returned exception > {noformat} > Exception in thread "main" org.apache.calcite.sql.parser.SqlParseException: > Non-query expression encountered in illegal context > at > org.apache.calcite.sql.parser.babel.SqlBabelParserImpl.convertException(SqlBabelParserImpl.java:355) > at > org.apache.calcite.sql.parser.babel.SqlBabelParserImpl.normalizeException(SqlBabelParserImpl.java:143) > at > org.apache.calcite.sql.parser.SqlParser.parseQuery(SqlParser.java:156) > at org.apache.calcite.sql.parser.SqlParser.parseStmt(SqlParser.java:181) > at org.apache.calcite.prepare.PlannerImpl.parse(PlannerImpl.java:174) > at org.apache.calcite.tools.Planner.parse(Planner.java:50) > at com.lab.calcite.App3.main(App3.java:69) > Caused by: org.apache.calcite.runtime.CalciteException: Non-query expression > encountered in illegal context > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) > at > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at java.lang.reflect.Constructor.newInstance(Constructor.java:423) > at > org.apache.calcite.runtime.Resources$ExInstWithCause.ex(Resources.java:463) > at org.apache.calcite.runtime.Resources$ExInst.ex(Resources.java:572) > at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:787) > at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:772) > at > org.apache.calcite.sql.parser.babel.SqlBabelParserImpl.checkNonQueryExpression(SqlBabelParserImpl.java:299) > at > org.apache.calcite.sql.parser.babel.SqlBabelParserImpl.Expression3(SqlBabelParserImpl.java:3387) > at > org.apache.calcite.sql.parser.babel.SqlBabelParserImpl.Expression2b(SqlBabelParserImpl.java:3117) > at > org.apache.calcite.sql.parser.babel.SqlBabelParserImpl.Expression2(SqlBabelParserImpl.java:3158) > at > org.apache.calcite.sql.parser.babel.SqlBabelParserImpl.Expression(SqlBabelParserImpl.java:3095) > at > org.apache.calcite.sql.parser.babel.SqlBabelParserImpl.LeafQueryOrExpr(SqlBabelParserImpl.java:3077) > at > org.apache.calcite.sql.parser.babel.SqlBabelParserImpl.QueryOrExpr(SqlBabelParserImpl.java:2999) > at > org.apache.calcite.sql.parser.babel.SqlBabelParserImpl.OrderedQueryOrExpr(SqlBabelParserImpl.java:471) > at > org.apache.calcite.sql.parser.babel.SqlBabelParserImpl.ParenthesizedQueryOrCommaList(SqlBabelParserImpl.java:638) > at > org.apache.calcite.sql.parser.babel.SqlBabelParserImpl.Expression3(SqlBabelParserImpl.java:3411) > at > org.apache.calcite.sql.parser.babel.SqlBabelParserImpl.Expression2b(SqlBabelParserImpl.java:3117) > at > org.apache.calcite.sql.parser.babel.SqlBabelParserImpl.Expression2(SqlBabelParserImpl.java:3158) > at > org.apache.calcite.sql.parser.babel.SqlBabelParserImpl.Expression(SqlBabelParserImpl.java:3095) > at > org.apache.calcite.sql.parser.babel.SqlBabelParserImpl.LeafQueryOrExpr(SqlBabelParserImpl.java:3077) > at > org.apache.calcite.sql.parser.babel.SqlBabelParserImpl.QueryOrExpr(SqlBabelParserImpl.java:2999) > at > org.apache.calcite.sql.parser.babel.SqlBabelParserImpl.OrderedQueryOrExpr(SqlBabelParserImpl.java:471) > at > org.apache.calcite.sql.parser.babel.SqlBabelParserImpl.ParenthesizedQueryOrCommaList(SqlBabelParserImpl.java:638) > at > org.apache.calcite.sql.parser.babel.SqlBabelParserImpl.Expression3(SqlBabelParserImpl.java:3411) > at > org.apache.calcite.sql.parser.babel.SqlBabelParserImpl.Expression2b(SqlBabelParserImpl.java:3117) > at > org.apache.calcite.sql.parser.babel.SqlBabelParserImpl.Expression2(SqlBabelParserImpl.java:3158)
[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&focusedCommentId=16833404#comment-16833404 ] Hongze Zhang commented on CALCITE-3046: --- PR opened at https://github.com/apache/calcite/pull/1199. > 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 > 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
[jira] [Updated] (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 updated CALCITE-3046: -- Summary: CompileException when inserting casted value of composited user defined type into table (was: CompileException when inserting casted value of composited user defined type to table) > 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 > > 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 > org.codehaus.janino.U
[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&focusedCommentId=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 > org.codehaus.janino.UnitCompiler.com
[jira] [Updated] (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:all-tabpanel ] Hongze Zhang updated CALCITE-3046: -- Description: 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 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) at org.codehaus.janino.Java$LocalVariableDeclarationStatement.accept(Java.java:3522) at org.codehaus.janino.UnitCompiler.compile(UnitCompiler.java:1487) at org.codehaus.janino.UnitCompiler.compileStatements(UnitComp
[jira] [Comment Edited] (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&focusedCommentId=16831423#comment-16831423 ] Hongze Zhang edited comment on CALCITE-3046 at 5/2/19 5:51 AM: --- This is another problem of UDT implementation, not related to CALCITE-3045. My assumption is that we can fix this issue by making 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. was (Author: zhztheplayer): 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:523
[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&focusedCommentId=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 > org.apache.calcite.sql.validate.SqlValidatorImpl.setValidatedNodeType(
[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&focusedCommentId=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 > org.apache.calcite.sql2
[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&focusedCommentId=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&focusedCommentId=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 > org.apache.calcite.test.CalciteAs
[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 org.apache.calcite.sql2rel.SqlNodeToRexConverterImpl.convertCall(SqlNo
[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&focusedCommentId=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 > org.apache.calcite.sql2rel.StandardCon
[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 org.apa
[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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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)