[jira] [Commented] (CALCITE-2743) TimeStamp confused in avatica jdbc
[
https://issues.apache.org/jira/browse/CALCITE-2743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16725527#comment-16725527
]
Marc Prud'hommeaux commented on CALCITE-2743:
-
We are seeing this problem as well. I believe it is due to a workaround for
MySQL Timestamp issues that is being applied throughout Calcite irrespective of
the data source, such that the offset to the local time to UTC is always being
applied to the timestamp:
[https://github.com/apache/calcite/blob/3fa29455664bec0056c436491b369e0cd72242ea/core/src/main/java/org/apache/calcite/adapter/jdbc/JdbcUtils.java#L159]
The following test case demonstrates the issue just using a ReflectiveSchema:
{code:java}
class TestTimestampOffsets extends TestCase {
public static Timestamp defaultTimestamp = Timestamp.valueOf("2018-12-25
12:00:00");
// Passes
public void testTimestampUTC() throws SQLException {
queryTimestamp(TimeZone.getTimeZone("UTC"));
}
// Fails: Expected: 2018-12-25 11:00:00.0 Actual: 2018-12-25 17:00:00.0
public void testTimestampChicago() throws SQLException {
queryTimestamp(TimeZone.getTimeZone("America/Chicago"));
}
public void queryTimestamp(TimeZone zone) throws SQLException {
var info = new Properties();
var conn = DriverManager.getConnection("jdbc:calcite:", info);
conn.unwrap(CalciteConnection.class).getRootSchema().add("TSCHEMA", new
ReflectiveSchema(new TSCHEMA()));
var deftz = TimeZone.getDefault();
TimeZone.setDefault(zone);
try {
try (var rs = conn.createStatement().executeQuery("SELECT TS FROM
TSCHEMA.TTABLE")) {
assertTrue(rs.next());
assertEquals(defaultTimestamp, rs.getObject(1));
}
} finally {
TimeZone.setDefault(deftz); // restore default TZ
}
}
public static class TSCHEMA {
public TemporalTable[] TTABLE = new TemporalTable[] { new
TemporalTable() };
public static class TemporalTable {
public Timestamp TS = defaultTimestamp;
}
}
}
{code}
> TimeStamp confused in avatica jdbc
> --
>
> Key: CALCITE-2743
> URL: https://issues.apache.org/jira/browse/CALCITE-2743
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Affects Versions: 1.10.0
>Reporter: shining
>Priority: Major
>
> I use Phoenix Query Server through avatica, Operation is as follows：
> 1. create table with sqlline-thin
>
> CREATE TABLE test_timezone(log_time TIMESTAMP NOT NULL PRIMARY KEY, id
> VARCHAR(40));
> 2. Upset data
>
> upsert into test_timezone values('2018-11-27 11:01:59.000','1’);
> 3. Query
> 0: jdbc:phoenix:thin:url=http://localhost:876> select * from
> test_timezone;
> +--+-+
> | LOG_TIME | ID |
> +-+--+
> | 2018-11-27 03:01:59 | 1 |
> +--+——+
> My local timeZone is GMT+8, and configured Phoenix
> “phoenix.query.dateFormatTimeZone=GMT+8”
> I also view code of avatica， when the timezone is GMT+8， getTimeStamp method
> will lose 8 hours：
> public Timestamp getTimestamp(Calendar calendar) throws SQLException {
> java.util.Date date = (java.util.Date) getObject();
> if (date == null) {
> return null;
> }
> long v = date.getTime();
> if (calendar != null) {
> v -= calendar.getTimeZone().getOffset(v);
> }
> return new Timestamp(v);
> }
> sqlline-thin use getString() method get the timestamp，it pass a null timezone
> to timestampAsString()
> So I have two doubtful places here：
> 1）I get correct time from phoenixResultSet， why reduce 8 hours ？
> 2）Can getString method be returned by getTimeStamp().toString():
> public String getString() throws SQLException {
> final long v = getLong();
> if (v == 0 && wasNull()) {
> return null;
> }
> return getTimeStamp(v, null).toString();
> }
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (CALCITE-2749) org.apache.calcite.sql.parser.SqlParseException: Lexical error at line 1, column 13. Encountered: "`" (96), after : ""
ambition created CALCITE-2749:
-
Summary: org.apache.calcite.sql.parser.SqlParseException: Lexical
error at line 1, column 13. Encountered: "`" (96), after : ""
Key: CALCITE-2749
URL: https://issues.apache.org/jira/browse/CALCITE-2749
Project: Calcite
Issue Type: Bug
Components: core, server
Affects Versions: 1.17.0
Reporter: ambition
Assignee: Julian Hyde
Dear all, I use ServerParserTest test sql like as :
{code:java}
INSERT INTO `test.db3.tb3` SELECT d * 2, e, g FROM test.db2.tb2 WHERE d < 3
UNION ALL (SELECT a * 2, b, c FROM test.db1.tb1)
{code}
then occur Exception:
{code:java}
java.lang.RuntimeException: Error while parsing SQL: INSERT INTO `test.db3.tb3`
SELECT d * 2, e, g FROM test.db2.tb2 WHERE d < 3 UNION ALL (SELECT a * 2, b, c
FROM test.db1.tb1)
at
org.apache.calcite.sql.parser.SqlParserTest$TesterImpl.parseStmtAndHandleEx(SqlParserTest.java:8503)
at
org.apache.calcite.sql.parser.SqlParserTest$TesterImpl.check(SqlParserTest.java:8488)
at org.apache.calcite.sql.parser.SqlParserTest$Sql.ok(SqlParserTest.java:8686)
at
org.apache.calcite.sql.parser.SqlParserTest.testInsertKInto(SqlParserTest.java:3460)
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: org.apache.calcite.sql.parser.SqlParseException: Lexical error at
line 1, column 13. Encountered: "`" (96), after : ""
at
org.apache.calcite.sql.parser.impl.SqlParserImpl.convertException(SqlParserImpl.java:354)
at
org.apache.calcite.sql.parser.impl.SqlParserImpl.normalizeException(SqlParserImpl.java:142)
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.sql.parser.SqlParserTest$TesterImpl.parseStmtAndHandleEx(SqlParserTest.java:8501)
... 25 more
Caused by: org.apache.calcite.sql.parser.impl.TokenMgrError: Lexical error at
line 1, column 13. Encountered: "`" (96), after : ""
at
org.apache.calcite.sql.parser.impl.SqlParserImplTokenManager.getNextToken(SqlParserImplTokenManager.java:15511)
at
org.apache.calcite.sql.parser.impl.SqlParserImpl.jj_scan_token(SqlParserImpl.java:24830)
at
org.apache.calcite.sql.parser.impl.SqlParserImpl.jj_3_416(SqlParserImpl.java:20325)
at
org.apache.calcite.sql.parser.impl.SqlParserImpl.jj_2_416(SqlParserImpl.java:10393)
at
org.apache.calcite.sql.parser.impl.SqlParserImpl.Identifier(SqlParserImpl.java:4405)
at
org.apache.calcite.sql.parser.impl.SqlParserImpl.CompoundIdentifier(SqlParserImpl.java:4503)
at
org.apache.calcite.sql.parser.impl.SqlParserImpl.SqlInsert(SqlParserImpl.java:1195)
at
org.apache.calcite.sql.parser.impl.SqlParserImpl.SqlStmt(SqlParserImpl.java:854)
at
org.apache.calcite.sql.parser.impl.SqlParserImpl.SqlStmtEof(SqlParserImpl.java:876)
at
org.apache.calcite.sql.parser.impl.SqlParserImpl.parseSqlStmtEof(SqlParserImpl.java:198)
at org.apache.calcite.sql.parser.SqlParser.parseQuery(SqlParser.java:148)
... 27 more
{code}
and use calcite-core model SqlParserTest also occur this error, is parser not
support or I config has error?
thanks.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2746) Cryptic exception when expression used in PARTITION BY clause in MATCH_RECOGNIZE
[
https://issues.apache.org/jira/browse/CALCITE-2746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16725388#comment-16725388
]
Julian Hyde commented on CALCITE-2746:
--
That's what the break is for! :)
Over my break, I'll be trying to push CALCITE-1935 over the finishing line.
> Cryptic exception when expression used in PARTITION BY clause in
> MATCH_RECOGNIZE
>
>
> Key: CALCITE-2746
> URL: https://issues.apache.org/jira/browse/CALCITE-2746
> Project: Calcite
> Issue Type: Bug
>Reporter: Dawid Wysakowicz
>Assignee: Julian Hyde
>Priority: Major
> Labels: match
>
> Query:
> {code}
> SELECT *
> FROM MyTable
> MATCH_RECOGNIZE (
> PARTITION BY (id + 2)
> ORDER BY proctime
> MEASURES
> A.id AS id
> PATTERN (A)
> DEFINE
> A AS name = 'a'
> ) AS T
> {code}
> results in exception:
> {code}
> Caused by: java.lang.ClassCastException: org.apache.calcite.sql.SqlBasicCall
> cannot be cast to org.apache.calcite.sql.SqlIdentifier
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateMatchRecognize(SqlValidatorImpl.java:4885)
> at
> org.apache.calcite.sql.validate.MatchRecognizeNamespace.validateImpl(MatchRecognizeNamespace.java:38)
> at
> org.apache.calcite.sql.validate.AbstractNamespace.validate(AbstractNamespace.java:84)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateNamespace(SqlValidatorImpl.java:972)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateQuery(SqlValidatorImpl.java:948)
> {code}
> I suggest improving it to give a proper hint that only input reference is
> supported.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-129) Support recursive WITH queries
[ https://issues.apache.org/jira/browse/CALCITE-129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16725180#comment-16725180 ] Stamatis Zampetakis commented on CALCITE-129: - Hi [~wa.moustafa], I see you were involved in the discussion about adding recursion to Calcite. Is there any work in progress related with this subject available somewhere? We may start working on this Jira in the near future, so it would be nice to know if there is already some code somewhere, which we can re-use. > Support recursive WITH queries > -- > > Key: CALCITE-129 > URL: https://issues.apache.org/jira/browse/CALCITE-129 > Project: Calcite > Issue Type: Improvement >Reporter: GitHub Import >Priority: Major > Labels: github-import > > Building on https://github.com/julianhyde/optiq/issues/128, enable the > RECURSIVE keyword. > This feature allows relations to be computed iteratively. Whereas > ([#128|https://github.com/JulianHyde/optiq/issues/128] | > [FLINK-128|https://issues.apache.org/jira/browse/OPTIQ-128]) was mainly a > parser/validator change, this feature requires significant changes to the > planner and runtime. > Imported from GitHub > Url: https://github.com/julianhyde/optiq/issues/129 > Created by: [julianhyde|https://github.com/julianhyde] > Labels: enhancement, > Created at: Tue Feb 11 20:29:35 CET 2014 > State: open -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-129) Support recursive WITH queries
[ https://issues.apache.org/jira/browse/CALCITE-129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16725176#comment-16725176 ] Stamatis Zampetakis commented on CALCITE-129: - Various Implementation choices regarding this subject were discussed in the dev list (see thread with title [Recursive query, graph query, Datalog|http://mail-archives.apache.org/mod_mbox/calcite-dev/201712.mbox/%3CCAPSgeESFyih9_hf9=uMWFN00BCR7sjf0T+FRY2=ary3ygm1...@mail.gmail.com%3E]). > Support recursive WITH queries > -- > > Key: CALCITE-129 > URL: https://issues.apache.org/jira/browse/CALCITE-129 > Project: Calcite > Issue Type: Improvement >Reporter: GitHub Import >Priority: Major > Labels: github-import > > Building on https://github.com/julianhyde/optiq/issues/128, enable the > RECURSIVE keyword. > This feature allows relations to be computed iteratively. Whereas > ([#128|https://github.com/JulianHyde/optiq/issues/128] | > [FLINK-128|https://issues.apache.org/jira/browse/OPTIQ-128]) was mainly a > parser/validator change, this feature requires significant changes to the > planner and runtime. > Imported from GitHub > Url: https://github.com/julianhyde/optiq/issues/129 > Created by: [julianhyde|https://github.com/julianhyde] > Labels: enhancement, > Created at: Tue Feb 11 20:29:35 CET 2014 > State: open -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CALCITE-2463) Silence ERROR logs from CalciteException, SqlValidatorException
[ https://issues.apache.org/jira/browse/CALCITE-2463?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Volodymyr Vysotskyi updated CALCITE-2463: - Fix Version/s: 1.19.0 > Silence ERROR logs from CalciteException, SqlValidatorException > --- > > Key: CALCITE-2463 > URL: https://issues.apache.org/jira/browse/CALCITE-2463 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.17.0 >Reporter: Vladimir Sitnikov >Assignee: Julian Hyde >Priority: Major > Fix For: 1.19.0 > > > CalciteException and SqlValidatorException log exceptions at ERROR level. > This is not appropriate since > 1) the exception might be expected by the caller > 2) exception might contain sensitive information > 3) ERROR level is not appropriate, since error in validation does not imply > business-level error. > I suggest to remove `LOGGER.error` calls from Calcite code. > Logging exceptions at TRACE level is fine from my point of view, so client > can enable trace logging if required for debug purposes. -- 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=16724930#comment-16724930
]
Hongze Zhang edited comment on CALCITE-2593 at 12/19/18 12:25 PM:
--
I would like to explain a bit more about how this bug could happen.
In current version of Calcite, composite collations get wiped to empty when
logical plan is initialized. The logic works well except for a specific case
(like what's described in title, when converting multiple collations to a
single in a RelNode), following is an example:
SQL:
{code:sql}
select y from (select y from (values (1, 2), (2, 3)) as t(x, y)) tab
{code}
LogicalPlan would be (pseudo):
{code:java}
LogicalProject[collation: [0]]
LogicalProject[collation: [0]]
LogicalValues[collation: [0, 1][1]]
{code}
In volcano planner, the initial state would be (pseudo):
{code:java}
set_1
subset_1_1[collation: [0]]
LogicalProject[collation: [0]]-[input: subset_2_1[0]]
set_2
subset_2_1[collation: [0]]
LogicalProject[collation: [0]]-[input: subset_3_1[]]
set_3
subset_3_1[collation: []]<- Collation get wiped by
simplification
LogicalValues[collation: [0, 1][1]]
{code}
After a enumerable-oriented transform (let's ignore rules other than enumerable
rules), the state would be:
{code:java}
set_1
subset_1_1[collation: [0]]
LogicalProject[collation: [0]]-[input: subset_2_1[0]] <-
Here triggers the error: the project can't find a input from subset_2_1.
set_2
subset_2_1[collation: [0]]
subset_2_2[collation: []]
EnumerableProject[collation: []]-[input: subset_3_1[]]
^ <- The project's collation get
wiped too since it's input's collation has changed to empty.
set_3
subset_3_1[collation: []]
EnumerableValues[collation: [0, 1][1]]
{code}
I came up with a quick solution for this issue, the code is here: [my
branch|https://github.com/zhztheplayer/calcite/tree/2593]. I feel the solution
is still not graceful enough, however until now I didn't find any better way.
Could someone please share some thoughts about this?
was (Author: zhztheplayer):
I would like to explain a bit more about how could this bug happen.
In current version of Calcite, composite collations get wiped to empty when
logical plan is initialized. The logic works well except for a specific case
(like what's described in title, when converting multiple collations to a
single in a RelNode), following is an example:
SQL:
{code:sql}
select y from (select y from (values (1, 2), (2, 3)) as t(x, y)) tab
{code}
LogicalPlan would be (pseudo):
{code}
LogicalProject[collation: [0]]
LogicalProject[collation: [0]]
LogicalValues[collation: [0, 1][1]]
{code}
In volcano planner, the initial state would be (pseudo):
{code}
set_1
subset_1_1[collation: [0]]
LogicalProject[collation: [0]]-[input: subset_2_1[0]]
set_2
subset_2_1[collation: [0]]
LogicalProject[collation: [0]]-[input: subset_3_1[]]
set_3
subset_3_1[collation: []]<- Collation get wiped by
simplification
LogicalValues[collation: [0, 1][1]]
{code}
After a enumerable-oriented transform (let's ignore rules other than enumerable
rules), the state would be:
{code}
set_1
subset_1_1[collation: [0]]
LogicalProject[collation: [0]]-[input: subset_2_1[0]] <-
Here triggers the error: the project can't find a input from subset_2_1.
set_2
subset_2_1[collation: [0]]
subset_2_2[collation: []]
EnumerableProject[collation: []]-[input: subset_3_1[]]
^ <- The project's collation get
wiped too since it's input's collation has changed to empty.
set_3
subset_3_1[collation: []]
EnumerableValues[collation: [0, 1][1]]
{code}
I came up with a quick solution for this issue, the code is here: [my
branch|https://github.com/zhztheplayer/calcite/tree/2593]. I feel the solution
is still not graceful enough, however until now I didn't find any better way.
Could someone please share some thoughts about this?
> 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
>Assignee: Julian Hyde
>Priority: Major
>
> Sample SQL:
> {code:java}
> select sum(X + 1) filter (where Y) as "SET" from (values (1, TRUE), (2,
> TRUE)) AS t(X, Y) limit
[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=16724930#comment-16724930
]
Hongze Zhang commented on CALCITE-2593:
---
I would like to explain a bit more about how could this bug happen.
In current version of Calcite, composite collations get wiped to empty when
logical plan is initialized. The logic works well except for a specific case
(like what's described in title, when converting multiple collations to a
single in a RelNode), following is an example:
SQL:
{code:sql}
select y from (select y from (values (1, 2), (2, 3)) as t(x, y)) tab
{code}
LogicalPlan would be (pseudo):
{code}
LogicalProject[collation: [0]]
LogicalProject[collation: [0]]
LogicalValues[collation: [0, 1][1]]
{code}
In volcano planner, the initial state would be (pseudo):
{code}
set_1
subset_1_1[collation: [0]]
LogicalProject[collation: [0]]-[input: subset_2_1[0]]
set_2
subset_2_1[collation: [0]]
LogicalProject[collation: [0]]-[input: subset_3_1[]]
set_3
subset_3_1[collation: []]<- Collation get wiped by
simplification
LogicalValues[collation: [0, 1][1]]
{code}
After a enumerable-oriented transform (let's ignore rules other than enumerable
rules), the state would be:
{code}
set_1
subset_1_1[collation: [0]]
LogicalProject[collation: [0]]-[input: subset_2_1[0]] <-
Here triggers the error: the project can't find a input from subset_2_1.
set_2
subset_2_1[collation: [0]]
subset_2_2[collation: []]
EnumerableProject[collation: []]-[input: subset_3_1[]]
^ <- The project's collation get
wiped too since it's input's collation has changed to empty.
set_3
subset_3_1[collation: []]
EnumerableValues[collation: [0, 1][1]]
{code}
I came up with a quick solution for this issue, the code is here: [my
branch|https://github.com/zhztheplayer/calcite/tree/2593]. I feel the solution
is still not graceful enough, however until now I didn't find any better way.
Could someone please share some thoughts about this?
> 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: Improvement
> Components: core
>Reporter: Hongze Zhang
>Assignee: Julian Hyde
>Priority: Major
>
> 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
>
[jira] [Commented] (CALCITE-2746) Cryptic exception when expression used in PARTITION BY clause in MATCH_RECOGNIZE
[
https://issues.apache.org/jira/browse/CALCITE-2746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16724807#comment-16724807
]
Dawid Wysakowicz commented on CALCITE-2746:
---
What we would also have to solve for {{PARTITION BY}} is naming the partition
keys, as they are returned as part of result. So we would need to support
expressions like: {{PARTITION BY (id + 1) AS derivedId}}.
If you think it makes more sense to support expressions in {{PARTITION BY}}
feel free to change the scope of this issue.
> Cryptic exception when expression used in PARTITION BY clause in
> MATCH_RECOGNIZE
>
>
> Key: CALCITE-2746
> URL: https://issues.apache.org/jira/browse/CALCITE-2746
> Project: Calcite
> Issue Type: Bug
>Reporter: Dawid Wysakowicz
>Assignee: Julian Hyde
>Priority: Major
> Labels: match
>
> Query:
> {code}
> SELECT *
> FROM MyTable
> MATCH_RECOGNIZE (
> PARTITION BY (id + 2)
> ORDER BY proctime
> MEASURES
> A.id AS id
> PATTERN (A)
> DEFINE
> A AS name = 'a'
> ) AS T
> {code}
> results in exception:
> {code}
> Caused by: java.lang.ClassCastException: org.apache.calcite.sql.SqlBasicCall
> cannot be cast to org.apache.calcite.sql.SqlIdentifier
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateMatchRecognize(SqlValidatorImpl.java:4885)
> at
> org.apache.calcite.sql.validate.MatchRecognizeNamespace.validateImpl(MatchRecognizeNamespace.java:38)
> at
> org.apache.calcite.sql.validate.AbstractNamespace.validate(AbstractNamespace.java:84)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateNamespace(SqlValidatorImpl.java:972)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateQuery(SqlValidatorImpl.java:948)
> {code}
> I suggest improving it to give a proper hint that only input reference is
> supported.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2746) Cryptic exception when expression used in PARTITION BY clause in MATCH_RECOGNIZE
[
https://issues.apache.org/jira/browse/CALCITE-2746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16724801#comment-16724801
]
Julian Hyde commented on CALCITE-2746:
--
IIRC the standard doesn’t allow expressions in GROUP BY or ORDER BY. But
they’re very useful in practice.
> Cryptic exception when expression used in PARTITION BY clause in
> MATCH_RECOGNIZE
>
>
> Key: CALCITE-2746
> URL: https://issues.apache.org/jira/browse/CALCITE-2746
> Project: Calcite
> Issue Type: Bug
>Reporter: Dawid Wysakowicz
>Assignee: Julian Hyde
>Priority: Major
> Labels: match
>
> Query:
> {code}
> SELECT *
> FROM MyTable
> MATCH_RECOGNIZE (
> PARTITION BY (id + 2)
> ORDER BY proctime
> MEASURES
> A.id AS id
> PATTERN (A)
> DEFINE
> A AS name = 'a'
> ) AS T
> {code}
> results in exception:
> {code}
> Caused by: java.lang.ClassCastException: org.apache.calcite.sql.SqlBasicCall
> cannot be cast to org.apache.calcite.sql.SqlIdentifier
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateMatchRecognize(SqlValidatorImpl.java:4885)
> at
> org.apache.calcite.sql.validate.MatchRecognizeNamespace.validateImpl(MatchRecognizeNamespace.java:38)
> at
> org.apache.calcite.sql.validate.AbstractNamespace.validate(AbstractNamespace.java:84)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateNamespace(SqlValidatorImpl.java:972)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateQuery(SqlValidatorImpl.java:948)
> {code}
> I suggest improving it to give a proper hint that only input reference is
> supported.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2746) Cryptic exception when expression used in PARTITION BY clause in MATCH_RECOGNIZE
[
https://issues.apache.org/jira/browse/CALCITE-2746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16724798#comment-16724798
]
Dawid Wysakowicz commented on CALCITE-2746:
---
I understand it wouldn't be hard to support expressions in {{PARTITION BY}},
though I am not sure if we should. SQL standard unfortunately says nothing what
is supported in PARTITION BY. Oracle throws exception in this case:
{{ORA-00904: : invalid identifier}}
> Cryptic exception when expression used in PARTITION BY clause in
> MATCH_RECOGNIZE
>
>
> Key: CALCITE-2746
> URL: https://issues.apache.org/jira/browse/CALCITE-2746
> Project: Calcite
> Issue Type: Bug
>Reporter: Dawid Wysakowicz
>Assignee: Julian Hyde
>Priority: Major
> Labels: match
>
> Query:
> {code}
> SELECT *
> FROM MyTable
> MATCH_RECOGNIZE (
> PARTITION BY (id + 2)
> ORDER BY proctime
> MEASURES
> A.id AS id
> PATTERN (A)
> DEFINE
> A AS name = 'a'
> ) AS T
> {code}
> results in exception:
> {code}
> Caused by: java.lang.ClassCastException: org.apache.calcite.sql.SqlBasicCall
> cannot be cast to org.apache.calcite.sql.SqlIdentifier
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateMatchRecognize(SqlValidatorImpl.java:4885)
> at
> org.apache.calcite.sql.validate.MatchRecognizeNamespace.validateImpl(MatchRecognizeNamespace.java:38)
> at
> org.apache.calcite.sql.validate.AbstractNamespace.validate(AbstractNamespace.java:84)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateNamespace(SqlValidatorImpl.java:972)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateQuery(SqlValidatorImpl.java:948)
> {code}
> I suggest improving it to give a proper hint that only input reference is
> supported.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2747) No exception when ambiguous column reference defined in PARTITION BY and MEASURES clause
[
https://issues.apache.org/jira/browse/CALCITE-2747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16724795#comment-16724795
]
Dawid Wysakowicz commented on CALCITE-2747:
---
Oracle gives: {{ORA-00918: column ambiguously defined}}
> No exception when ambiguous column reference defined in PARTITION BY and
> MEASURES clause
> -
>
> Key: CALCITE-2747
> URL: https://issues.apache.org/jira/browse/CALCITE-2747
> Project: Calcite
> Issue Type: Bug
>Reporter: Dawid Wysakowicz
>Assignee: Julian Hyde
>Priority: Major
> Labels: match
>
> Query:
> {code}
> SELECT *
> FROM MyTable
> MATCH_RECOGNIZE (
> PARTITION BY id
> ORDER BY proctime
> MEASURES
> A.id AS id
> PATTERN (A)
> DEFINE
> A AS name = 'a'
> ) AS T
> {code}
> should fail because of ambiguous {{id}} column.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
