[jira] [Created] (CALCITE-5129) Exception thrown writing to a closed stream with SPNEGO authentication at DEBUG
Josh Elser created CALCITE-5129:
---
Summary: Exception thrown writing to a closed stream with SPNEGO
authentication at DEBUG
Key: CALCITE-5129
URL: https://issues.apache.org/jira/browse/CALCITE-5129
Project: Calcite
Issue Type: Bug
Reporter: Josh Elser
Assignee: Josh Elser
{noformat}
2022-05-03 18:27:57,651 WARN org.eclipse.jetty.server.HttpChannelState:
unhandled due to prior sendError
org.eclipse.jetty.io.EofException: Closed
at
org.eclipse.jetty.server.HttpOutput.checkWritable(HttpOutput.java:762)
at org.eclipse.jetty.server.HttpOutput.write(HttpOutput.java:792)
at java.io.OutputStream.write(OutputStream.java:75)
at
org.apache.calcite.avatica.server.AbstractAvaticaHandler.isUserPermitted(AbstractAvaticaHandler.java:71)
at
org.apache.calcite.avatica.server.AvaticaProtobufHandler.handle(AvaticaProtobufHandler.java:103)
at
org.eclipse.jetty.server.handler.HandlerList.handle(HandlerList.java:59)
at
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
at org.eclipse.jetty.server.Server.handle(Server.java:516)
at
org.eclipse.jetty.server.HttpChannel.lambda$handle$1(HttpChannel.java:388)
at org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:633)
at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:380)
at
org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:277)
at
org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:311)
at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:105)
at
org.eclipse.jetty.io.ssl.SslConnection$DecryptedEndPoint.onFillable(SslConnection.java:540)
at
org.eclipse.jetty.io.ssl.SslConnection.onFillable(SslConnection.java:395)
at
org.eclipse.jetty.io.ssl.SslConnection$2.succeeded(SslConnection.java:161)
at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:105)
at org.eclipse.jetty.io.ChannelEndPoint$1.run(ChannelEndPoint.java:104)
at
org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:336)
at
org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:313)
at
org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:171)
at
org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:129)
at
org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:383)
at
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:882)
at
org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:1036)
{noformat}
Trying to test CALCITE-4152 behind Apache Knox, I noticed the following in the
server-side logs.
It appears that we end up spitting out an exception when another layer of code
has already called {{sendError()}} which prevents any further writes to the
OutputStream (destined back to the client). I think this is cosmetic, but I'm
not 100% certain at this point.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (CALCITE-5125) Extend "||" operator to work with arrays
[ https://issues.apache.org/jira/browse/CALCITE-5125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17531200#comment-17531200 ] Dmitry Sysolyatin commented on CALCITE-5125: Can someone review PR? > Extend "||" operator to work with arrays > > > Key: CALCITE-5125 > URL: https://issues.apache.org/jira/browse/CALCITE-5125 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Dmitry Sysolyatin >Assignee: Dmitry Sysolyatin >Priority: Major > Labels: pull-request-available > > "||" operator can be used only for string concatenation but it would be good > to use it also for array concatenation as PostgreSQL -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Comment Edited] (CALCITE-4999) ARRAY function should return an array of scalars if subquery returns 1 column
[
https://issues.apache.org/jira/browse/CALCITE-4999?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17531197#comment-17531197
]
Dmitry Sysolyatin edited comment on CALCITE-4999 at 5/3/22 1:33 PM:
[~julianhyde]
Ok, I will think about it. But changing constructors is not so bad idea for me.
Assume that someone implements Collect interface and updates calcite version
then his/her implementation will fail in runtime in case of subquery. Runtime
error is more dangerous than compile error
was (Author: dmsysolyatin):
[~julianhyde]
Ok, I will think about it. But changing constructors is not so bad idea for me.
Assume that someone implements Collect class and updates calcite version then
his/her implementation will fail in runtime in case of subquery. Runtime error
is more dangerous than compile error
> ARRAY function should return an array of scalars if subquery returns 1 column
> -
>
> Key: CALCITE-4999
> URL: https://issues.apache.org/jira/browse/CALCITE-4999
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Dmitry Sysolyatin
>Assignee: Dmitry Sysolyatin
>Priority: Major
> Labels: pull-request-available
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> At the moment `array` function returns [RecordType ARRAY] if subquery is
> passed like an argument.
> {code:java}
> SELECT array(select 'toast.' || x from unnest(ARRAY['1','2']) x){code}
> But Sql standard says:
> {code:java}
> 6.38
> Function
> Specify construction of an array.
> Format
> ::=
>
> |
> [...]
> ::=
> ARRAY
> Syntax Rules
> [...]
> 3) If is specified, then
> a) The QE simply contained in the shall
> be of degree 1 (one). Let ET be the declared type of the column in the result
> of .
> b) The declared type of the is array with
> element type ET and maximum cardinality equal to the implementation-defined
> maximum cardinality IMDC for such array types.
> {code}
> Proposed solution is to return an array of scalars (e.g. INTEGER ARRAY) when
> the query returns 1 column, and continue to return an array of ROW when the
> query has 2 or more columns. And do the same for MULTISET.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (CALCITE-4999) ARRAY function should return an array of scalars if subquery returns 1 column
[
https://issues.apache.org/jira/browse/CALCITE-4999?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17531197#comment-17531197
]
Dmitry Sysolyatin commented on CALCITE-4999:
[~julianhyde]
Ok, I will think about it. But changing constructors is not so bad idea for me.
Assume that someone implements Collect class and updates calcite version then
his/her implementation will fail in runtime in case of subquery. Runtime error
is more dangerous than compile error
> ARRAY function should return an array of scalars if subquery returns 1 column
> -
>
> Key: CALCITE-4999
> URL: https://issues.apache.org/jira/browse/CALCITE-4999
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Dmitry Sysolyatin
>Assignee: Dmitry Sysolyatin
>Priority: Major
> Labels: pull-request-available
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> At the moment `array` function returns [RecordType ARRAY] if subquery is
> passed like an argument.
> {code:java}
> SELECT array(select 'toast.' || x from unnest(ARRAY['1','2']) x){code}
> But Sql standard says:
> {code:java}
> 6.38
> Function
> Specify construction of an array.
> Format
> ::=
>
> |
> [...]
> ::=
> ARRAY
> Syntax Rules
> [...]
> 3) If is specified, then
> a) The QE simply contained in the shall
> be of degree 1 (one). Let ET be the declared type of the column in the result
> of .
> b) The declared type of the is array with
> element type ET and maximum cardinality equal to the implementation-defined
> maximum cardinality IMDC for such array types.
> {code}
> Proposed solution is to return an array of scalars (e.g. INTEGER ARRAY) when
> the query returns 1 column, and continue to return an array of ROW when the
> query has 2 or more columns. And do the same for MULTISET.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Created] (CALCITE-5128) SQL parser doesn't seem to understand UPDATE statements with fqns
Mike Hearn created CALCITE-5128:
---
Summary: SQL parser doesn't seem to understand UPDATE statements
with fqns
Key: CALCITE-5128
URL: https://issues.apache.org/jira/browse/CALCITE-5128
Project: Calcite
Issue Type: Bug
Components: core
Affects Versions: 1.30.0
Reporter: Mike Hearn
The following SQL fails to parse:
{{UPDATE pz.Moon t SET t.name = ? WHERE t.obj_id = ? AND t.image IS NULL AND
t.mass = ? AND t.name LIKE ? ESCAPE '#' AND t.parent_id = ?}}
This sort of query is generated by DataGrip to update cells. The error is:
{{Caused by: org.apache.calcite.sql.parser.impl.ParseException: Encountered "."
at line 1, column 23.}}
{{Was expecting:}}
{{ "=" ...}}
{{ }}
{{ at
org.apache.calcite.sql.parser.impl.SqlParserImpl.generateParseException(SqlParserImpl.java:37112)}}
{{ at
org.apache.calcite.sql.parser.impl.SqlParserImpl.jj_consume_token(SqlParserImpl.java:36926)}}
{{ at
org.apache.calcite.sql.parser.impl.SqlParserImpl.SqlUpdate(SqlParserImpl.java:7285)}}
{{ at
org.apache.calcite.sql.parser.impl.SqlParserImpl.SqlStmt(SqlParserImpl.java:3806)}}
{{ at
org.apache.calcite.sql.parser.impl.SqlParserImpl.SqlStmtEof(SqlParserImpl.java:3828)}}
{{ at
org.apache.calcite.sql.parser.impl.SqlParserImpl.parseSqlStmtEof(SqlParserImpl.java:201)}}
{{ at
org.apache.calcite.sql.parser.SqlParser.parseQuery(SqlParser.java:158)}}
{{ ... 35 more}}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Comment Edited] (CALCITE-3557) ClassCastException for using nested multiset or array inside multiset
[
https://issues.apache.org/jira/browse/CALCITE-3557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17531102#comment-17531102
]
Jiajun Xie edited comment on CALCITE-3557 at 5/3/22 9:12 AM:
-
Here is a new pr in avatica:
[https://github.com/apache/calcite-avatica/pull/179]. Welcome to comment.
And add UT in CALCITE: https://github.com/apache/calcite/pull/2790
was (Author: jiajunbernoulli):
Here is a new pr in avatica:
https://github.com/apache/calcite-avatica/pull/179. Welcome to comment.
> ClassCastException for using nested multiset or array inside multiset
> -
>
> Key: CALCITE-3557
> URL: https://issues.apache.org/jira/browse/CALCITE-3557
> Project: Calcite
> Issue Type: Bug
>Reporter: Wang Yanlin
>Assignee: Jiajun Xie
>Priority: Major
> Labels: pull-request-available
> Attachments: image-2021-12-25-18-06-21-066.png,
> image-2022-01-23-17-16-54-076.png, screenshot-1.png
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> {code:java}
> // JdbcTest
> @Test public void testNestedMultiset() {
> CalciteAssert.that()
> .query("select multiset[ARRAY[1, 2], ARRAY[3, 4]]")
> .returns("EXPR$0=[[1, 2], [3, 4]]\n");
> CalciteAssert.that()
> .query("select multiset[multiset[1, 2], multiset[3, 4]]")
> .returns("EXPR$0=[[1, 2], [3, 4]]\n");
> }
> {code}
> Got
> {code:java}
> java.lang.ClassCastException: [Ljava.lang.Object; cannot be cast to
> java.lang.Integer
> at
> org.apache.calcite.avatica.util.AbstractCursor$IntAccessor.getInt(AbstractCursor.java:541)
> at
> org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.convertValue(AbstractCursor.java:1318)
> at
> org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.getObject(AbstractCursor.java:1299)
> at
> org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.getArray(AbstractCursor.java:1352)
> at
> org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.convertValue(AbstractCursor.java:1326)
> at
> org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.getObject(AbstractCursor.java:1299)
> at
> org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.getArray(AbstractCursor.java:1352)
> at org.apache.calcite.avatica.AvaticaSite.get(AvaticaSite.java:305)
> at
> org.apache.calcite.avatica.AvaticaResultSet.getObject(AvaticaResultSet.java:393)
> at
> org.apache.calcite.test.CalciteAssert$ResultSetFormatter.rowToString(CalciteAssert.java:1978)
> at
> org.apache.calcite.test.CalciteAssert$ResultSetFormatter.resultSet(CalciteAssert.java:1966)
> at
> org.apache.calcite.test.CalciteAssert.lambda$checkResult$2(CalciteAssert.java:303)
> at
> org.apache.calcite.test.CalciteAssert.assertQuery(CalciteAssert.java:544)
> at
> org.apache.calcite.test.CalciteAssert$AssertQuery.lambda$returns$1(CalciteAssert.java:1514)
> at
> org.apache.calcite.test.CalciteAssert$AssertQuery.withConnection(CalciteAssert.java:1446)
> at
> org.apache.calcite.test.CalciteAssert$AssertQuery.returns(CalciteAssert.java:1512)
> at
> org.apache.calcite.test.CalciteAssert$AssertQuery.returns(CalciteAssert.java:1495)
> at
> org.apache.calcite.test.CalciteAssert$AssertQuery.returns(CalciteAssert.java:1458)
> at
> org.apache.calcite.test.JdbcTest.testNestedMultiset(JdbcTest.java:2057)
> 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
[jira] [Updated] (CALCITE-3557) ClassCastException for using nested multiset or array inside multiset
[
https://issues.apache.org/jira/browse/CALCITE-3557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-3557:
Labels: pull-request-available (was: )
> ClassCastException for using nested multiset or array inside multiset
> -
>
> Key: CALCITE-3557
> URL: https://issues.apache.org/jira/browse/CALCITE-3557
> Project: Calcite
> Issue Type: Bug
>Reporter: Wang Yanlin
>Assignee: Jiajun Xie
>Priority: Major
> Labels: pull-request-available
> Attachments: image-2021-12-25-18-06-21-066.png,
> image-2022-01-23-17-16-54-076.png, screenshot-1.png
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> {code:java}
> // JdbcTest
> @Test public void testNestedMultiset() {
> CalciteAssert.that()
> .query("select multiset[ARRAY[1, 2], ARRAY[3, 4]]")
> .returns("EXPR$0=[[1, 2], [3, 4]]\n");
> CalciteAssert.that()
> .query("select multiset[multiset[1, 2], multiset[3, 4]]")
> .returns("EXPR$0=[[1, 2], [3, 4]]\n");
> }
> {code}
> Got
> {code:java}
> java.lang.ClassCastException: [Ljava.lang.Object; cannot be cast to
> java.lang.Integer
> at
> org.apache.calcite.avatica.util.AbstractCursor$IntAccessor.getInt(AbstractCursor.java:541)
> at
> org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.convertValue(AbstractCursor.java:1318)
> at
> org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.getObject(AbstractCursor.java:1299)
> at
> org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.getArray(AbstractCursor.java:1352)
> at
> org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.convertValue(AbstractCursor.java:1326)
> at
> org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.getObject(AbstractCursor.java:1299)
> at
> org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.getArray(AbstractCursor.java:1352)
> at org.apache.calcite.avatica.AvaticaSite.get(AvaticaSite.java:305)
> at
> org.apache.calcite.avatica.AvaticaResultSet.getObject(AvaticaResultSet.java:393)
> at
> org.apache.calcite.test.CalciteAssert$ResultSetFormatter.rowToString(CalciteAssert.java:1978)
> at
> org.apache.calcite.test.CalciteAssert$ResultSetFormatter.resultSet(CalciteAssert.java:1966)
> at
> org.apache.calcite.test.CalciteAssert.lambda$checkResult$2(CalciteAssert.java:303)
> at
> org.apache.calcite.test.CalciteAssert.assertQuery(CalciteAssert.java:544)
> at
> org.apache.calcite.test.CalciteAssert$AssertQuery.lambda$returns$1(CalciteAssert.java:1514)
> at
> org.apache.calcite.test.CalciteAssert$AssertQuery.withConnection(CalciteAssert.java:1446)
> at
> org.apache.calcite.test.CalciteAssert$AssertQuery.returns(CalciteAssert.java:1512)
> at
> org.apache.calcite.test.CalciteAssert$AssertQuery.returns(CalciteAssert.java:1495)
> at
> org.apache.calcite.test.CalciteAssert$AssertQuery.returns(CalciteAssert.java:1458)
> at
> org.apache.calcite.test.JdbcTest.testNestedMultiset(JdbcTest.java:2057)
> 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.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:33)
> at
> com.
[jira] [Commented] (CALCITE-3557) ClassCastException for using nested multiset or array inside multiset
[
https://issues.apache.org/jira/browse/CALCITE-3557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17531102#comment-17531102
]
Jiajun Xie commented on CALCITE-3557:
-
Here is a new pr in avatica:
https://github.com/apache/calcite-avatica/pull/179. Welcome to comment.
> ClassCastException for using nested multiset or array inside multiset
> -
>
> Key: CALCITE-3557
> URL: https://issues.apache.org/jira/browse/CALCITE-3557
> Project: Calcite
> Issue Type: Bug
>Reporter: Wang Yanlin
>Assignee: Jiajun Xie
>Priority: Major
> Attachments: image-2021-12-25-18-06-21-066.png,
> image-2022-01-23-17-16-54-076.png, screenshot-1.png
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {code:java}
> // JdbcTest
> @Test public void testNestedMultiset() {
> CalciteAssert.that()
> .query("select multiset[ARRAY[1, 2], ARRAY[3, 4]]")
> .returns("EXPR$0=[[1, 2], [3, 4]]\n");
> CalciteAssert.that()
> .query("select multiset[multiset[1, 2], multiset[3, 4]]")
> .returns("EXPR$0=[[1, 2], [3, 4]]\n");
> }
> {code}
> Got
> {code:java}
> java.lang.ClassCastException: [Ljava.lang.Object; cannot be cast to
> java.lang.Integer
> at
> org.apache.calcite.avatica.util.AbstractCursor$IntAccessor.getInt(AbstractCursor.java:541)
> at
> org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.convertValue(AbstractCursor.java:1318)
> at
> org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.getObject(AbstractCursor.java:1299)
> at
> org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.getArray(AbstractCursor.java:1352)
> at
> org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.convertValue(AbstractCursor.java:1326)
> at
> org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.getObject(AbstractCursor.java:1299)
> at
> org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.getArray(AbstractCursor.java:1352)
> at org.apache.calcite.avatica.AvaticaSite.get(AvaticaSite.java:305)
> at
> org.apache.calcite.avatica.AvaticaResultSet.getObject(AvaticaResultSet.java:393)
> at
> org.apache.calcite.test.CalciteAssert$ResultSetFormatter.rowToString(CalciteAssert.java:1978)
> at
> org.apache.calcite.test.CalciteAssert$ResultSetFormatter.resultSet(CalciteAssert.java:1966)
> at
> org.apache.calcite.test.CalciteAssert.lambda$checkResult$2(CalciteAssert.java:303)
> at
> org.apache.calcite.test.CalciteAssert.assertQuery(CalciteAssert.java:544)
> at
> org.apache.calcite.test.CalciteAssert$AssertQuery.lambda$returns$1(CalciteAssert.java:1514)
> at
> org.apache.calcite.test.CalciteAssert$AssertQuery.withConnection(CalciteAssert.java:1446)
> at
> org.apache.calcite.test.CalciteAssert$AssertQuery.returns(CalciteAssert.java:1512)
> at
> org.apache.calcite.test.CalciteAssert$AssertQuery.returns(CalciteAssert.java:1495)
> at
> org.apache.calcite.test.CalciteAssert$AssertQuery.returns(CalciteAssert.java:1458)
> at
> org.apache.calcite.test.JdbcTest.testNestedMultiset(JdbcTest.java:2057)
> 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.junit.IdeaTestRunner$Repeater
[jira] [Updated] (CALCITE-5127) Error when executing query with subquery in select list that uses outer column of array type
[
https://issues.apache.org/jira/browse/CALCITE-5127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitry Sysolyatin updated CALCITE-5127:
---
Component/s: core
> Error when executing query with subquery in select list that uses outer
> column of array type
>
>
> Key: CALCITE-5127
> URL: https://issues.apache.org/jira/browse/CALCITE-5127
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Dmitry Sysolyatin
>Priority: Major
>
> The following queries fail:
> {code}
> SELECT ARRAY(SELECT s.x) FROM (SELECT ARRAY[1,2,3] as x) s;
> SELECT ARRAY(SELECT * FROM UNNEST(s.x) y) FROM (SELECT ARRAY[1,2,3] as x) s;
> SELECT (SELECT CARDINALITY(s.x) LIMIT 1) FROM (SELECT ARRAY[1,2,3] as x) s;
>
> {code}
> With exception:
> {code}
> Caused by: java.lang.ClassCastException: java.lang.Integer cannot be cast to
> java.util.List
> {code}
> You can find test cases for this task in
> https://github.com/apache/calcite/commit/27e68ded2c3bea7d7af73dd1dc156e46fb3591a8
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (CALCITE-5127) Error when executing query with subquery in select list that uses outer column of array type
[
https://issues.apache.org/jira/browse/CALCITE-5127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitry Sysolyatin updated CALCITE-5127:
---
Description:
The following queries fail:
{code}
SELECT ARRAY(SELECT s.x) FROM (SELECT ARRAY[1,2,3] as x) s;
SELECT ARRAY(SELECT * FROM UNNEST(s.x) y) FROM (SELECT ARRAY[1,2,3] as x) s;
SELECT (SELECT CARDINALITY(s.x) LIMIT 1) FROM (SELECT ARRAY[1,2,3] as x) s;
{code}
With exception:
{code}
Caused by: java.lang.ClassCastException: java.lang.Integer cannot be cast to
java.util.List
{code}
You can find test cases for this task in
https://github.com/apache/calcite/commit/27e68ded2c3bea7d7af73dd1dc156e46fb3591a8
was:
The following queries fail:
{code}
CalciteAssert.that()
.query("SELECT ARRAY(SELECT s.x)\n" +
"FROM (SELECT ARRAY[1,2,3] as x) s")
.returnsCount(1);
CalciteAssert.that()
.query("SELECT ARRAY(SELECT * FROM UNNEST(s.x) y)\n" +
"FROM (SELECT ARRAY[1,2,3] as x) s")
.returnsCount(1);
CalciteAssert.that()
.query("SELECT (SELECT CARDINALITY(s.x) LIMIT 1)\n" +
"FROM (SELECT ARRAY[1,2,3] as x) s")
.returnsUnordered("EXPR$0=3");
{code}
With exception:
Caused by: java.lang.ClassCastException: java.lang.Integer cannot be cast to
java.util.List
You can find test cases for this task in
https://github.com/apache/calcite/commit/27e68ded2c3bea7d7af73dd1dc156e46fb3591a8
> Error when executing query with subquery in select list that uses outer
> column of array type
>
>
> Key: CALCITE-5127
> URL: https://issues.apache.org/jira/browse/CALCITE-5127
> Project: Calcite
> Issue Type: Bug
>Reporter: Dmitry Sysolyatin
>Priority: Major
>
> The following queries fail:
> {code}
> SELECT ARRAY(SELECT s.x) FROM (SELECT ARRAY[1,2,3] as x) s;
> SELECT ARRAY(SELECT * FROM UNNEST(s.x) y) FROM (SELECT ARRAY[1,2,3] as x) s;
> SELECT (SELECT CARDINALITY(s.x) LIMIT 1) FROM (SELECT ARRAY[1,2,3] as x) s;
>
> {code}
> With exception:
> {code}
> Caused by: java.lang.ClassCastException: java.lang.Integer cannot be cast to
> java.util.List
> {code}
> You can find test cases for this task in
> https://github.com/apache/calcite/commit/27e68ded2c3bea7d7af73dd1dc156e46fb3591a8
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Created] (CALCITE-5127) Error when executing query with subquery in select list that uses outer column of array type
Dmitry Sysolyatin created CALCITE-5127:
--
Summary: Error when executing query with subquery in select list
that uses outer column of array type
Key: CALCITE-5127
URL: https://issues.apache.org/jira/browse/CALCITE-5127
Project: Calcite
Issue Type: Bug
Reporter: Dmitry Sysolyatin
The following queries fail:
{code}
CalciteAssert.that()
.query("SELECT ARRAY(SELECT s.x)\n" +
"FROM (SELECT ARRAY[1,2,3] as x) s")
.returnsCount(1);
CalciteAssert.that()
.query("SELECT ARRAY(SELECT * FROM UNNEST(s.x) y)\n" +
"FROM (SELECT ARRAY[1,2,3] as x) s")
.returnsCount(1);
CalciteAssert.that()
.query("SELECT (SELECT CARDINALITY(s.x) LIMIT 1)\n" +
"FROM (SELECT ARRAY[1,2,3] as x) s")
.returnsUnordered("EXPR$0=3");
{code}
With exception:
Caused by: java.lang.ClassCastException: java.lang.Integer cannot be cast to
java.util.List
You can find test cases for this task in
https://github.com/apache/calcite/commit/27e68ded2c3bea7d7af73dd1dc156e46fb3591a8
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Closed] (CALCITE-3658) TableModify of Update contains correlated variable by mistake.
[
https://issues.apache.org/jira/browse/CALCITE-3658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ruben Q L closed CALCITE-3658.
--
> TableModify of Update contains correlated variable by mistake.
> --
>
> Key: CALCITE-3658
> URL: https://issues.apache.org/jira/browse/CALCITE-3658
> Project: Calcite
> Issue Type: Improvement
>Reporter: Jin Xing
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.22.0
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> UPDATE clause like below
> {code:java}
> update emp set empno = empno + 1
> {code}
> will be converted to
> {code:java}
> LogicalTableModify(table=[[CATALOG, SALES, EMP]], operation=[UPDATE],
> updateColumnList=[[EMPNO]], sourceExpressionList=[[+($cor0.EMPNO, 1)]],
> flattened=[true])
> LogicalProject(EMPNO=[$0], ENAME=[$1], JOB=[$2], MGR=[$3], HIREDATE=[$4],
> SAL=[$5], COMM=[$6], DEPTNO=[$7], SLACKER=[$8], EXPR$0=[+($0, 1)])
> LogicalTableScan(table=[[CATALOG, SALES, EMP]])
> {code}
> However the correlated variables $cor0.EMPNO should not exist in
> *sourceExpressionList*.
> It also brings trouble when convert TableModify back to Sql string.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (CALCITE-3658) TableModify of Update contains correlated variable by mistake.
[
https://issues.apache.org/jira/browse/CALCITE-3658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17531076#comment-17531076
]
Jiajun Xie commented on CALCITE-3658:
-
OK, in order to avoid the problem of JIRA workflow, I closed the ticket. Let's
discuss new solutions in CALCITE-5122.
> TableModify of Update contains correlated variable by mistake.
> --
>
> Key: CALCITE-3658
> URL: https://issues.apache.org/jira/browse/CALCITE-3658
> Project: Calcite
> Issue Type: Improvement
>Reporter: Jin Xing
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.22.0
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> UPDATE clause like below
> {code:java}
> update emp set empno = empno + 1
> {code}
> will be converted to
> {code:java}
> LogicalTableModify(table=[[CATALOG, SALES, EMP]], operation=[UPDATE],
> updateColumnList=[[EMPNO]], sourceExpressionList=[[+($cor0.EMPNO, 1)]],
> flattened=[true])
> LogicalProject(EMPNO=[$0], ENAME=[$1], JOB=[$2], MGR=[$3], HIREDATE=[$4],
> SAL=[$5], COMM=[$6], DEPTNO=[$7], SLACKER=[$8], EXPR$0=[+($0, 1)])
> LogicalTableScan(table=[[CATALOG, SALES, EMP]])
> {code}
> However the correlated variables $cor0.EMPNO should not exist in
> *sourceExpressionList*.
> It also brings trouble when convert TableModify back to Sql string.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Resolved] (CALCITE-3658) TableModify of Update contains correlated variable by mistake.
[
https://issues.apache.org/jira/browse/CALCITE-3658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jiajun Xie resolved CALCITE-3658.
-
Resolution: Fixed
> TableModify of Update contains correlated variable by mistake.
> --
>
> Key: CALCITE-3658
> URL: https://issues.apache.org/jira/browse/CALCITE-3658
> Project: Calcite
> Issue Type: Improvement
>Reporter: Jin Xing
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.22.0
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> UPDATE clause like below
> {code:java}
> update emp set empno = empno + 1
> {code}
> will be converted to
> {code:java}
> LogicalTableModify(table=[[CATALOG, SALES, EMP]], operation=[UPDATE],
> updateColumnList=[[EMPNO]], sourceExpressionList=[[+($cor0.EMPNO, 1)]],
> flattened=[true])
> LogicalProject(EMPNO=[$0], ENAME=[$1], JOB=[$2], MGR=[$3], HIREDATE=[$4],
> SAL=[$5], COMM=[$6], DEPTNO=[$7], SLACKER=[$8], EXPR$0=[+($0, 1)])
> LogicalTableScan(table=[[CATALOG, SALES, EMP]])
> {code}
> However the correlated variables $cor0.EMPNO should not exist in
> *sourceExpressionList*.
> It also brings trouble when convert TableModify back to Sql string.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
