[jira] [Commented] (CALCITE-3127) Support ALTER VIEW Statement
[
https://issues.apache.org/jira/browse/CALCITE-3127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16863716#comment-16863716
]
pingle wang commented on CALCITE-3127:
--
so we can support like :
{code:java}
ALTER VIEW view ADD constraint;
ALTER VIEW view MODIFY CONSTRAINT constraint [RELY | NORELY];
ALTER VIEW view DROP CONSTRAINT constraint;
ALTER VIEW view COMPILE;
ALTER VIEW view [READ ONLY | READ WRITE ];
{code}
> Support ALTER VIEW Statement
>
>
> Key: CALCITE-3127
> URL: https://issues.apache.org/jira/browse/CALCITE-3127
> Project: Calcite
> Issue Type: Improvement
> Components: server
>Affects Versions: 1.19.0
>Reporter: pingle wang
>Priority: Major
> Labels: pull-request-available
> Fix For: next
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> support alter view statement :
> {code:java}
> ALTER VIEW name
> [ '(' columnName [, columnName ]* ')' ]
> AS query
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-3127) Support ALTER VIEW Statement
[
https://issues.apache.org/jira/browse/CALCITE-3127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16863698#comment-16863698
]
Julian Hyde commented on CALCITE-3127:
--
I think this is a pointless command, as are ALTER VIEW in MySQL and SQL Server,
because it requires 'AS query'.
Why does Hive support ALTER VIEW? Only for compatibility with MySQL (see
HIVE-3834). Good grief.
Oracle's ALTER VIEW statement makes sense to me, because you can ADD, MODIFY,
DROP or COMPILE and you don't have to - in fact you cannot - re-specify 'AS
query'.
> Support ALTER VIEW Statement
>
>
> Key: CALCITE-3127
> URL: https://issues.apache.org/jira/browse/CALCITE-3127
> Project: Calcite
> Issue Type: Improvement
> Components: server
>Affects Versions: 1.19.0
>Reporter: pingle wang
>Priority: Major
> Labels: pull-request-available
> Fix For: next
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> support alter view statement :
> {code:java}
> ALTER VIEW name
> [ '(' columnName [, columnName ]* ')' ]
> AS query
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-3120) MongoAdapterTest.testGroupByAvgSumCount fails due the order of sort query
[
https://issues.apache.org/jira/browse/CALCITE-3120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16863667#comment-16863667
]
Andrei Sereda commented on CALCITE-3120:
Yes order shouldn't matter (after {{$group}}).
I think the problem is that this test is run only on real mongo (see
{{MongoAssertions.assumeRealMongoInstance()}}) at some point Project / Sort
expression order changed upstream and the test wasn't updated.
On the positive side, I might have found an alternative to
[fongo|https://github.com/fakemongo/fongo] where all integration tests pass. If
so, we may not need "double mongo" test configuration as before (real vs fongo).
Otherwise I'm not sure what is best way to keep string query checker up-to-date
in calcite. Eg. sometimes it may rewrite {{A = B}} into {{B = A}} and the test
will fail.
> MongoAdapterTest.testGroupByAvgSumCount fails due the order of sort query
> -
>
> Key: CALCITE-3120
> URL: https://issues.apache.org/jira/browse/CALCITE-3120
> Project: Calcite
> Issue Type: Bug
> Components: mongodb-adapter
>Affects Versions: 1.19.0
>Reporter: Stamatis Zampetakis
>Assignee: Stamatis Zampetakis
>Priority: Major
>
> The MongoAdapterTest.testGroupByAvgSumCount fails because $sort operator does
> not appear at the middle of the query but in the end.
> {noformat}
> org.junit.ComparisonFailure:
> expected and actual Mongo queries (pipelines) do not match
> expected:<...$project" : {
> "[POP" : "$pop",
> "STATE" : "$state"
> }
> }
> {
> "$group" : {
> "_id" : "$STATE",
> "_1" : {
> "$sum" : "$POP"
> },
> "_2" : {
> "$sum" : {
> "$cond" : [{
> "$eq" : ["POP", null]
> }, 0, 1]
> }
> }
> }
> }
> {
> "$project" : {
> "STATE" : "$_id",
> "_1" : "$_1",
> "_2" : "$_2"
> }
> }
> {
> "$sort" : {
> "STATE" : 1
> }
> }
> {
> "$project" : {
> "STATE" : 1,
> "A" : {
> "$divide" : [{
> "$cond" : [{
> "$eq" : ["$_2", {
> "$literal" : 0
> }]
> }, null, "$_1"]
> }, "$_2"]
> },
> "S" : {
> "$cond" : [{
> "$eq" : ["$_2", {
> "$literal" : 0
> }]
> }, null, "$_1"]
> },
> "C" : "$_2"]
> }
> }> but was:<...$project" : {
> "[STATE" : "$state",
> "POP" : "$pop"
> }
> }
> {
> "$group" : {
> "_id" : "$STATE",
> "_1" : {
> "$sum" : "$POP"
> },
> "_2" : {
> "$sum" : {
> "$cond" : [{
> "$eq" : ["POP", null]
> }, 0, 1]
> }
> }
> }
> }
> {
> "$project" : {
> "STATE" : "$_id",
> "_1" : "$_1",
> "_2" : "$_2"
> }
> }
> {
> "$project" : {
> "STATE" : 1,
> "A" : {
> "$divide" : [{
> "$cond" : [{
> "$eq" : ["$_2", {
> "$literal" : 0
> }]
> }, null, "$_1"]
> }, "$_2"]
> },
> "S" : {
> "$cond" : [{
> "$eq" : ["$_2", {
> "$literal" : 0
> }]
> }, null, "$_1"]
> },
> "C" : "$_2"
> }
> }
> {
> "$sort" : {
> "STATE" : 1]
> }
> }>
> {noformat}
--
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=16863628#comment-16863628
]
Andrei Sereda commented on CALCITE-3073:
I think it is similar issue to {{_id}} column in elastic. See discussion on
[dev
list|https://lists.apache.org/thread.html/91ac1a5215e22afa9abee924426e05cfbcf257aae6858741308ed7b8@%3Cdev.calcite.apache.org%3E].
Can this be available only if requested explicitly ?
> 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.
> In other words, if the app runs at first time and user want to consume the
> past data, user must set the value of
> '{color:#707070}*auto.offset.reset'*{color} parameter to *earliest*.
> {quote}{{auto.offset.reset：What to do when there is no initial offset in
> Kafka or if the current offset does not exist any more on the server (e.g.
> because that data has been deleted):}}
> * earliest: automatically reset the offset to the earliest offset
> * latest: automatically reset the offset to the latest offset
> * none: throw exception to the consumer if no previous offset is found for
> the consumer's group
> * anything else: throw exception to the consumer.{quote}
> for example, suppose data in Kafka is retained for 7 days and you just want
> to read from the data of yesterday, if you could not control the start
> timestamp, you can only read from the earliest offset, it's very inefficient.
> If supporting to consume from special timestamp in KafkaAdapter will be a
> good idea for some cases.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-3127) Support ALTER VIEW Statement
[
https://issues.apache.org/jira/browse/CALCITE-3127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16863610#comment-16863610
]
pingle wang commented on CALCITE-3127:
--
Consider this situation, if db only supports CREATE VIEW [IF NOT EXISTS], it
will support ALTER VIEW. Of course, similar to mysql db is to support CREATE OR
REPLACE VIEW and also support ALTER VIEW, thanks.
mysql doc:
[https://dev.mysql.com/doc/refman/8.0/en/create-view.html]
{code:java}
CREATE
[OR REPLACE]
[ALGORITHM = {UNDEFINED | MERGE | TEMPTABLE}]
[DEFINER = user]
[SQL SECURITY { DEFINER | INVOKER }]
VIEW view_name [(column_list)]
AS select_statement
[WITH [CASCADED | LOCAL] CHECK OPTION]
{code}
[https://dev.mysql.com/doc/refman/8.0/en/alter-view.html]
{code:java}
ALTER
[ALGORITHM = {UNDEFINED | MERGE | TEMPTABLE}]
[DEFINER = user]
[SQL SECURITY { DEFINER | INVOKER }]
VIEW view_name [(column_list)]
AS select_statement
[WITH [CASCADED | LOCAL] CHECK OPTION]
{code}
sql server doc:
[https://docs.microsoft.com/en-us/sql/t-sql/statements/alter-view-transact-sql?view=sql-server-2017]
{code:java}
ALTER VIEW [ schema_name . ] view_name [ ( column [ ,...n ] ) ]
[ WITH [ ,...n ] ]
AS select_statement
[ WITH CHECK OPTION ] [ ; ]
::=
{
[ ENCRYPTION ]
[ SCHEMABINDING ]
[ VIEW_METADATA ]
}{code}
hive doc:
[https://cwiki.apache.org/confluence/display/Hive/LanguageManual+DDL#LanguageManualDDL-Create/Drop/AlterView]
{code:java}
Alter View As Select:
ALTER VIEW [db_name.]view_name AS select_statement;
{code}
> Support ALTER VIEW Statement
>
>
> Key: CALCITE-3127
> URL: https://issues.apache.org/jira/browse/CALCITE-3127
> Project: Calcite
> Issue Type: Improvement
> Components: server
>Affects Versions: 1.19.0
>Reporter: pingle wang
>Priority: Major
> Labels: pull-request-available
> Fix For: next
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> support alter view statement :
> {code:java}
> ALTER VIEW name
> [ '(' columnName [, columnName ]* ')' ]
> AS query
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-3121) VolcanoPlanner hangs due to removing ORDER BY from sub-query
[
https://issues.apache.org/jira/browse/CALCITE-3121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16863367#comment-16863367
]
Volodymyr Vysotskyi commented on CALCITE-3121:
--
[~julianhyde], can I merge this PR to include it into the release?
> VolcanoPlanner hangs due to removing ORDER BY from sub-query
>
>
> Key: CALCITE-3121
> URL: https://issues.apache.org/jira/browse/CALCITE-3121
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.19.0
>Reporter: Bohdan Kazydub
>Assignee: Danny Chan
>Priority: Blocker
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> After the fix for CALCITE-2798 some queries hang during planning in
> VolcanoPlanner (similar issue was reported in CALCITE-2223).
> Here is a test case which should be added to the {{RelOptRulesTest}} class:
> {code:java}
> @Test public void testSubQueryWithOrderByHang() {
> String sql = "select n.n_regionkey from ( select * from "
> + "( select * from sales.customer) t order by t.n_regionkey) n where
> n.n_nationkey >1 ";
> VolcanoPlanner planner = new VolcanoPlanner(null, null);
> planner.addRelTraitDef(ConventionTraitDef.INSTANCE);
> Tester dynamicTester = createDynamicTester().withDecorrelation(true)
> .withClusterFactory(
> relOptCluster -> RelOptCluster.create(planner,
> relOptCluster.getRexBuilder()));
> RelRoot root = dynamicTester.convertSqlToRel(sql);
> String planBefore = NL + RelOptUtil.toString(root.rel);
> getDiffRepos().assertEquals("planBefore", "${planBefore}", planBefore);
> PushProjector.ExprCondition exprCondition = expr -> {
> if (expr instanceof RexCall) {
> RexCall call = (RexCall) expr;
> return
> "item".equals(call.getOperator().getName().toLowerCase(Locale.ROOT));
> }
> return false;
> };
> RuleSet ruleSet =
> RuleSets.ofList(
> FilterProjectTransposeRule.INSTANCE,
> FilterMergeRule.INSTANCE,
> ProjectMergeRule.INSTANCE,
> new ProjectFilterTransposeRule(Project.class, Filter .class,
> RelFactories.LOGICAL_BUILDER, exprCondition),
> EnumerableRules.ENUMERABLE_PROJECT_RULE,
> EnumerableRules.ENUMERABLE_FILTER_RULE,
> EnumerableRules.ENUMERABLE_SORT_RULE,
> EnumerableRules.ENUMERABLE_LIMIT_RULE,
> EnumerableRules.ENUMERABLE_TABLE_SCAN_RULE);
> Program program = Programs.of(ruleSet);
> RelTraitSet toTraits =
> root.rel.getCluster().traitSet()
> .replace(0, EnumerableConvention.INSTANCE);
> RelNode relAfter = program.run(planner, root.rel, toTraits,
> Collections.emptyList(), Collections.emptyList());
> String planAfter = NL + RelOptUtil.toString(relAfter);
> getDiffRepos().assertEquals("planAfter", "${planAfter}", planAfter);
> }
> {code}
> Please note that if {{LIMIT }} is added to the sub-query with order by
> (so it is not removed due to the fix for CALCITE-2798) the test succeeds.
> Though the issue with hanging is more general, I think that if it wouldn't be
> fixed, the fix for CALCITE-2798 should be reverted to reduce cases when
> planner may hang.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-3127) Support ALTER VIEW Statement
[
https://issues.apache.org/jira/browse/CALCITE-3127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16863305#comment-16863305
]
Julian Hyde commented on CALCITE-3127:
--
How would this differ from {{CREATE OR REPLACE VIEW}}? I presume there is a DB
that has this syntax, and you are trying to emulate it. If so, which DB?
The philosophical difference between an ALTER statement and a CREATE OR REPLACE
statement is that ALTER specifies deltas - eg. alter table add one column -
where as a CREATE OR REPLACE statement repeats the entire definition. For
views, CREATE OR REPLACE seems more appropriate.
> Support ALTER VIEW Statement
>
>
> Key: CALCITE-3127
> URL: https://issues.apache.org/jira/browse/CALCITE-3127
> Project: Calcite
> Issue Type: Improvement
> Components: server
>Affects Versions: 1.19.0
>Reporter: pingle wang
>Priority: Major
> Labels: pull-request-available
> Fix For: next
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> support alter view statement :
> {code:java}
> ALTER VIEW name
> [ '(' columnName [, columnName ]* ')' ]
> AS query
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-3119) Deprecate Linq4j CorrelateJoinType (in favor of JoinType)
[
https://issues.apache.org/jira/browse/CALCITE-3119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16863301#comment-16863301
]
Michael Mior commented on CALCITE-3119:
---
Fixed in
[{{4e89fdd}}|https://github.com/apache/calcite/commit/4e89fddab415a1e04b82c7d69960e399f608949f].
> Deprecate Linq4j CorrelateJoinType (in favor of JoinType)
> -
>
> Key: CALCITE-3119
> URL: https://issues.apache.org/jira/browse/CALCITE-3119
> Project: Calcite
> Issue Type: Task
>Reporter: Ruben Quesada Lopez
>Assignee: Ruben Quesada Lopez
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.20.0
>
> Time Spent: 2h
> Remaining Estimate: 0h
>
> CALCITE-2968 introduced in Linq4j a new (more general) enum JoinType. As a
> result, we have right now two enums for (almost) the same purpose:
> CorrelateJoinType (used for Correlation, thus defining only INNER, LEFT,
> SEMI, ANTI) and the new JoinType (can be used for any purpose, defining all
> types of join, mirroring core's JoinRelType).
> The idea is to flag CorrelateJoinType as deprecated, and replace all its
> usages by JoinType.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (CALCITE-3119) Deprecate Linq4j CorrelateJoinType (in favor of JoinType)
[ https://issues.apache.org/jira/browse/CALCITE-3119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Mior resolved CALCITE-3119. --- Resolution: Fixed > Deprecate Linq4j CorrelateJoinType (in favor of JoinType) > - > > Key: CALCITE-3119 > URL: https://issues.apache.org/jira/browse/CALCITE-3119 > Project: Calcite > Issue Type: Task >Reporter: Ruben Quesada Lopez >Assignee: Ruben Quesada Lopez >Priority: Major > Labels: pull-request-available > Fix For: 1.20.0 > > Time Spent: 2h > Remaining Estimate: 0h > > CALCITE-2968 introduced in Linq4j a new (more general) enum JoinType. As a > result, we have right now two enums for (almost) the same purpose: > CorrelateJoinType (used for Correlation, thus defining only INNER, LEFT, > SEMI, ANTI) and the new JoinType (can be used for any purpose, defining all > types of join, mirroring core's JoinRelType). > The idea is to flag CorrelateJoinType as deprecated, and replace all its > usages by JoinType. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CALCITE-3127) Support ALTER VIEW Statement
[
https://issues.apache.org/jira/browse/CALCITE-3127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Mior updated CALCITE-3127:
--
Fix Version/s: (was: 1.20.0)
> Support ALTER VIEW Statement
>
>
> Key: CALCITE-3127
> URL: https://issues.apache.org/jira/browse/CALCITE-3127
> Project: Calcite
> Issue Type: Improvement
> Components: server
>Affects Versions: 1.19.0
>Reporter: pingle wang
>Priority: Major
> Labels: pull-request-available
> Fix For: next
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> support alter view statement :
> {code:java}
> ALTER VIEW name
> [ '(' columnName [, columnName ]* ')' ]
> AS query
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-3119) Deprecate Linq4j CorrelateJoinType (in favor of JoinType)
[ https://issues.apache.org/jira/browse/CALCITE-3119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16863295#comment-16863295 ] Julian Hyde commented on CALCITE-3119: -- +1 > Deprecate Linq4j CorrelateJoinType (in favor of JoinType) > - > > Key: CALCITE-3119 > URL: https://issues.apache.org/jira/browse/CALCITE-3119 > Project: Calcite > Issue Type: Task >Reporter: Ruben Quesada Lopez >Assignee: Ruben Quesada Lopez >Priority: Major > Labels: pull-request-available > Fix For: 1.20.0 > > Time Spent: 1h 50m > Remaining Estimate: 0h > > CALCITE-2968 introduced in Linq4j a new (more general) enum JoinType. As a > result, we have right now two enums for (almost) the same purpose: > CorrelateJoinType (used for Correlation, thus defining only INNER, LEFT, > SEMI, ANTI) and the new JoinType (can be used for any purpose, defining all > types of join, mirroring core's JoinRelType). > The idea is to flag CorrelateJoinType as deprecated, and replace all its > usages by JoinType. -- 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=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=16863277#comment-16863277
]
Stamatis Zampetakis commented on CALCITE-2804:
--
Thanks for keeping an eye on this [~zhztheplayer]. If there are not major
changes I don't think you need to open a new PR. You can fetch the work of
[~jszeluga] do the (minor?) modifications and push it to master. This also
allows [~jszeluga] to keep the credit for the work he has done so far!
> 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 20m
> 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=16863256#comment-16863256
]
Justin Szeluga commented on CALCITE-2804:
-
[~zhztheplayer] Yeah that's fine go ahead. I've been busy as of late and
haven't had a chance to work on this
> 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 10m
> Remaining Estimate: 0h
>
> When trying to execute a simple statement of
> {code:java}
> select cast("__time" as timestamp) from my_datasource limit 10;{code}
> the query fails with a 500 error
>
> {code:java}
> Caused by: java.io.IOException: Server returned HTTP response code: 500 for
> URL: http://localhost:58082/druid/v2/?pretty
> at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(Unknown Source)
> at sun.net.www.protocol.http.HttpURLConnection.getInputStream(Unknown Source)
> at org.apache.calcite.runtime.HttpUtils.executeMethod(HttpUtils.java:137)
> at org.apache.calcite.runtime.HttpUtils.post(HttpUtils.java:110)
> at
> org.apache.calcite.adapter.druid.DruidConnectionImpl.request(DruidConnectionImpl.java:109)
> ... 29 more
> {code}
> because the JSON generated is incorrect. Here is the generated JSON
>
>
> {code:java}
> {
> "queryType": "scan",
> "dataSource": "my_datasource",
> "intervals": [
> "1900-01-01T00:00:00.000Z/3000-01-01T00:00:00.000Z"
> ],
> "virtualColumns": [
> {
> "type": "expression",
> "name": "vc",
> "expression":
> "timestamp_parse(timestamp_format(\"__time\",'-MM-dd\\u0027T\\u0027HH:mm:ss.SSS\\u0027Z\\u0027','America/New_York'),'','UTC')",
> "outputType": "LONG"
> }
> ],
> "columns": [
> "vc"
> ],
> "resultFormat": "compactedList",
> "limit": 10
> }
> {code}
> There are two problems. -First, the "__time" dimension is not formatted
> correctly in timestamp_format. The escaped quotes need to be removed.-
> Also, the call to timestamp_parse is incorrect. If a timezone is going to be
> provided then a date time format needs to be provided as well. Currently, it
> is only empty string
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2804) Druid adapter: Cast does not work when casting to timestamp
[
https://issues.apache.org/jira/browse/CALCITE-2804?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16863235#comment-16863235
]
Hongze Zhang commented on CALCITE-2804:
---
Hi [~jszeluga], I see there are some comments in PR haven't been addressed yet.
Since the issue might be a blocker of Calcite's next release I'd like to add
some changes on top of your work if you don't mind. (I have to open a new PR :)
)
> Druid adapter: Cast does not work when casting to timestamp
> ---
>
> Key: CALCITE-2804
> URL: https://issues.apache.org/jira/browse/CALCITE-2804
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.18.0
>Reporter: Justin Szeluga
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.20.0
>
> Time Spent: 4h
> Remaining Estimate: 0h
>
> When trying to execute a simple statement of
> {code:java}
> select cast("__time" as timestamp) from my_datasource limit 10;{code}
> the query fails with a 500 error
>
> {code:java}
> Caused by: java.io.IOException: Server returned HTTP response code: 500 for
> URL: http://localhost:58082/druid/v2/?pretty
> at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(Unknown Source)
> at sun.net.www.protocol.http.HttpURLConnection.getInputStream(Unknown Source)
> at org.apache.calcite.runtime.HttpUtils.executeMethod(HttpUtils.java:137)
> at org.apache.calcite.runtime.HttpUtils.post(HttpUtils.java:110)
> at
> org.apache.calcite.adapter.druid.DruidConnectionImpl.request(DruidConnectionImpl.java:109)
> ... 29 more
> {code}
> because the JSON generated is incorrect. Here is the generated JSON
>
>
> {code:java}
> {
> "queryType": "scan",
> "dataSource": "my_datasource",
> "intervals": [
> "1900-01-01T00:00:00.000Z/3000-01-01T00:00:00.000Z"
> ],
> "virtualColumns": [
> {
> "type": "expression",
> "name": "vc",
> "expression":
> "timestamp_parse(timestamp_format(\"__time\",'-MM-dd\\u0027T\\u0027HH:mm:ss.SSS\\u0027Z\\u0027','America/New_York'),'','UTC')",
> "outputType": "LONG"
> }
> ],
> "columns": [
> "vc"
> ],
> "resultFormat": "compactedList",
> "limit": 10
> }
> {code}
> There are two problems. -First, the "__time" dimension is not formatted
> correctly in timestamp_format. The escaped quotes need to be removed.-
> Also, the call to timestamp_parse is incorrect. If a timezone is going to be
> provided then a date time format needs to be provided as well. Currently, it
> is only empty string
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-3119) Deprecate Linq4j CorrelateJoinType (in favor of JoinType)
[ https://issues.apache.org/jira/browse/CALCITE-3119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16863021#comment-16863021 ] Ruben Quesada Lopez commented on CALCITE-3119: -- [~michaelmior], in my opinion, yes. > Deprecate Linq4j CorrelateJoinType (in favor of JoinType) > - > > Key: CALCITE-3119 > URL: https://issues.apache.org/jira/browse/CALCITE-3119 > Project: Calcite > Issue Type: Task >Reporter: Ruben Quesada Lopez >Assignee: Ruben Quesada Lopez >Priority: Major > Labels: pull-request-available > Fix For: 1.20.0 > > Time Spent: 1h 50m > Remaining Estimate: 0h > > CALCITE-2968 introduced in Linq4j a new (more general) enum JoinType. As a > result, we have right now two enums for (almost) the same purpose: > CorrelateJoinType (used for Correlation, thus defining only INNER, LEFT, > SEMI, ANTI) and the new JoinType (can be used for any purpose, defining all > types of join, mirroring core's JoinRelType). > The idea is to flag CorrelateJoinType as deprecated, and replace all its > usages by JoinType. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-3119) Deprecate Linq4j CorrelateJoinType (in favor of JoinType)
[ https://issues.apache.org/jira/browse/CALCITE-3119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16863017#comment-16863017 ] Michael Mior commented on CALCITE-3119: --- Is this ready to be merged? > Deprecate Linq4j CorrelateJoinType (in favor of JoinType) > - > > Key: CALCITE-3119 > URL: https://issues.apache.org/jira/browse/CALCITE-3119 > Project: Calcite > Issue Type: Task >Reporter: Ruben Quesada Lopez >Assignee: Ruben Quesada Lopez >Priority: Major > Labels: pull-request-available > Fix For: 1.20.0 > > Time Spent: 1h 50m > Remaining Estimate: 0h > > CALCITE-2968 introduced in Linq4j a new (more general) enum JoinType. As a > result, we have right now two enums for (almost) the same purpose: > CorrelateJoinType (used for Correlation, thus defining only INNER, LEFT, > SEMI, ANTI) and the new JoinType (can be used for any purpose, defining all > types of join, mirroring core's JoinRelType). > The idea is to flag CorrelateJoinType as deprecated, and replace all its > usages by JoinType. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CALCITE-3109) Improvements on algebraic operators to express recursive queries (RepeatUnion & TableSpool)
[
https://issues.apache.org/jira/browse/CALCITE-3109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-3109:
Labels: pull-request-available (was: )
> Improvements on algebraic operators to express recursive queries (RepeatUnion
> & TableSpool)
> ---
>
> Key: CALCITE-3109
> URL: https://issues.apache.org/jira/browse/CALCITE-3109
> Project: Calcite
> Issue Type: Task
>Reporter: Ruben Quesada Lopez
>Assignee: Ruben Quesada Lopez
>Priority: Minor
> Labels: pull-request-available
> Fix For: 1.21.0
>
>
> After the implementation of CALCITE-2812, there are some pending details to
> be addressed in order to make the RepeatUnion and TableSpool more consistent.
> TableSpool:
> - Replace {{String tableName}} with a {{Table}} (perhaps wrapped in a
> {{RelOptTable}}).
> RepeatUnion:
> - Rename {{maxRep}} as {{iterationLimit}}. Change this field to allow all
> integer values, and treat all negative values as "no limit".
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CALCITE-3109) Improvements on algebraic operators to express recursive queries (RepeatUnion & TableSpool)
[
https://issues.apache.org/jira/browse/CALCITE-3109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ruben Quesada Lopez updated CALCITE-3109:
-
Fix Version/s: 1.21.0
> Improvements on algebraic operators to express recursive queries (RepeatUnion
> & TableSpool)
> ---
>
> Key: CALCITE-3109
> URL: https://issues.apache.org/jira/browse/CALCITE-3109
> Project: Calcite
> Issue Type: Task
>Reporter: Ruben Quesada Lopez
>Assignee: Ruben Quesada Lopez
>Priority: Minor
> Fix For: 1.21.0
>
>
> After the implementation of CALCITE-2812, there are some pending details to
> be addressed in order to make the RepeatUnion and TableSpool more consistent.
> TableSpool:
> - Replace {{String tableName}} with a {{Table}} (perhaps wrapped in a
> {{RelOptTable}}).
> RepeatUnion:
> - Rename {{maxRep}} as {{iterationLimit}}. Change this field to allow all
> integer values, and treat all negative values as "no limit".
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CALCITE-3060) Materialized view: "target out of range" error
[
https://issues.apache.org/jira/browse/CALCITE-3060?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-3060:
Labels: pull-request-available (was: )
> Materialized view: "target out of range" error
> --
>
> Key: CALCITE-3060
> URL: https://issues.apache.org/jira/browse/CALCITE-3060
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.19.0
>Reporter: Anton Haidai
>Priority: Major
> Labels: pull-request-available
>
> "MaterializationTest":
> {code}
> @Test public void testPermutationError() {
> CalciteAssert.that()
> .withMaterializations(
> HR_FKUK_MODEL,
> "m0",
> "select min(\"salary\"), count(*), max(\"salary\"),
> sum(\"salary\"), \"empid\" from \"emps\" group by \"empid\"",
> "m1",
> "select min(\"salary\"), count(*), max(\"salary\"),
> sum(\"salary\"), \"deptno\", \"empid\" from \"emps\" group by \"empid\",
> \"deptno\""
> )
> .query(
> "select count(*), \"empid\" from \"emps\" group by \"empid\"")
> .enableMaterializations(true)
> .explainContains("EnumerableTableScan(table=[[hr, m0]])")
> .sameResultWithMaterializationsDisabled();
> }
> {code}
> Error (looks like the mapping is expected to be bijection but it is not):
> {code}
> Caused by: java.lang.IllegalArgumentException: target out of range
> at org.apache.calcite.util.Permutation.(Permutation.java:69)
> at org.apache.calcite.util.mapping.Mappings.bijection(Mappings.java:394)
> at
> org.apache.calcite.rel.mutable.MutableRels.createProject(MutableRels.java:142)
> at
> org.apache.calcite.plan.SubstitutionVisitor.unifyAggregates(SubstitutionVisitor.java:1269)
> at
> org.apache.calcite.plan.SubstitutionVisitor$AggregateOnProjectToAggregateUnifyRule.apply(SubstitutionVisitor.java:1345)
> at
> org.apache.calcite.plan.SubstitutionVisitor.go(SubstitutionVisitor.java:531)
> at
> org.apache.calcite.plan.SubstitutionVisitor.go(SubstitutionVisitor.java:466)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (CALCITE-3060) Materialized view: "target out of range" error
[
https://issues.apache.org/jira/browse/CALCITE-3060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16862799#comment-16862799
]
Feng Zhu edited comment on CALCITE-3060 at 6/13/19 7:46 AM:
Hi, [~hyuan]. This issue is similar to the issue I found in CALCITE-3087. We
should fix the mapping beheavior.
{code:java}
query
==
Aggregate(groupSet: {0}, groupSets: [{0}], calls: [COUNT()])
Project(projects: [$0, $3])
Scan(table: [hr, emps])
target
==
Aggregate(groupSet: {0}, groupSets: [{0}], calls: [MIN($1), COUNT(), MAX($1),
SUM($1)])
Project(projects: [$0, $3])
Scan(table: [hr, emps]){code}
When _unifyAggregate(query, target)_, a MutableProject will be generated.
{code:java}
MutableRels.createProject(target, projects)
//empid ($0), count($2)
projects = [0, 2]
// call MutableRels.createProject
Mappings.bijection(projects{code}
However, the posList is not always a bijection mapping. We should use
*INVERSE_SURJECTION* mapping, as that in RelFieldTrimmer.
was (Author: donnyzone):
Hi, [~hyuan]. This issue is similar to the issue I found in CALCITE-3087. We
should fix the mapping beheavior.
{code:java}
query
==
Aggregate(groupSet: {0}, groupSets: [{0}], calls: [COUNT()])
Project(projects: [$0, $3])
Scan(table: [hr, emps])
target
==
Aggregate(groupSet: {0}, groupSets: [{0}], calls: [MIN($1), COUNT(), MAX($1),
SUM($1)])
Project(projects: [$0, $3])
Scan(table: [hr, emps]){code}
When _unifyAggregate(query, target)_, a MutableProject will be generated.
{code:java}
MutableRels.createProject(target, projects)
//empid ($0), count($2)
projects = [0, 2]
// call MutableRels.createProject
Mappings.bijection(projects{code}
However, the posList is not always a bijection mapping. We should use
*INVERSE_SURJECTION* mapping, as that in RelFieldTrimmer.
> Materialized view: "target out of range" error
> --
>
> Key: CALCITE-3060
> URL: https://issues.apache.org/jira/browse/CALCITE-3060
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.19.0
>Reporter: Anton Haidai
>Assignee: Feng Zhu
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> "MaterializationTest":
> {code}
> @Test public void testPermutationError() {
> CalciteAssert.that()
> .withMaterializations(
> HR_FKUK_MODEL,
> "m0",
> "select min(\"salary\"), count(*), max(\"salary\"),
> sum(\"salary\"), \"empid\" from \"emps\" group by \"empid\"",
> "m1",
> "select min(\"salary\"), count(*), max(\"salary\"),
> sum(\"salary\"), \"deptno\", \"empid\" from \"emps\" group by \"empid\",
> \"deptno\""
> )
> .query(
> "select count(*), \"empid\" from \"emps\" group by \"empid\"")
> .enableMaterializations(true)
> .explainContains("EnumerableTableScan(table=[[hr, m0]])")
> .sameResultWithMaterializationsDisabled();
> }
> {code}
> Error (looks like the mapping is expected to be bijection but it is not):
> {code}
> Caused by: java.lang.IllegalArgumentException: target out of range
> at org.apache.calcite.util.Permutation.(Permutation.java:69)
> at org.apache.calcite.util.mapping.Mappings.bijection(Mappings.java:394)
> at
> org.apache.calcite.rel.mutable.MutableRels.createProject(MutableRels.java:142)
> at
> org.apache.calcite.plan.SubstitutionVisitor.unifyAggregates(SubstitutionVisitor.java:1269)
> at
> org.apache.calcite.plan.SubstitutionVisitor$AggregateOnProjectToAggregateUnifyRule.apply(SubstitutionVisitor.java:1345)
> at
> org.apache.calcite.plan.SubstitutionVisitor.go(SubstitutionVisitor.java:531)
> at
> org.apache.calcite.plan.SubstitutionVisitor.go(SubstitutionVisitor.java:466)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (CALCITE-3060) Materialized view: "target out of range" error
[
https://issues.apache.org/jira/browse/CALCITE-3060?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Feng Zhu reassigned CALCITE-3060:
-
Assignee: Feng Zhu
> Materialized view: "target out of range" error
> --
>
> Key: CALCITE-3060
> URL: https://issues.apache.org/jira/browse/CALCITE-3060
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.19.0
>Reporter: Anton Haidai
>Assignee: Feng Zhu
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> "MaterializationTest":
> {code}
> @Test public void testPermutationError() {
> CalciteAssert.that()
> .withMaterializations(
> HR_FKUK_MODEL,
> "m0",
> "select min(\"salary\"), count(*), max(\"salary\"),
> sum(\"salary\"), \"empid\" from \"emps\" group by \"empid\"",
> "m1",
> "select min(\"salary\"), count(*), max(\"salary\"),
> sum(\"salary\"), \"deptno\", \"empid\" from \"emps\" group by \"empid\",
> \"deptno\""
> )
> .query(
> "select count(*), \"empid\" from \"emps\" group by \"empid\"")
> .enableMaterializations(true)
> .explainContains("EnumerableTableScan(table=[[hr, m0]])")
> .sameResultWithMaterializationsDisabled();
> }
> {code}
> Error (looks like the mapping is expected to be bijection but it is not):
> {code}
> Caused by: java.lang.IllegalArgumentException: target out of range
> at org.apache.calcite.util.Permutation.(Permutation.java:69)
> at org.apache.calcite.util.mapping.Mappings.bijection(Mappings.java:394)
> at
> org.apache.calcite.rel.mutable.MutableRels.createProject(MutableRels.java:142)
> at
> org.apache.calcite.plan.SubstitutionVisitor.unifyAggregates(SubstitutionVisitor.java:1269)
> at
> org.apache.calcite.plan.SubstitutionVisitor$AggregateOnProjectToAggregateUnifyRule.apply(SubstitutionVisitor.java:1345)
> at
> org.apache.calcite.plan.SubstitutionVisitor.go(SubstitutionVisitor.java:531)
> at
> org.apache.calcite.plan.SubstitutionVisitor.go(SubstitutionVisitor.java:466)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-3060) Materialized view: "target out of range" error
[
https://issues.apache.org/jira/browse/CALCITE-3060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16862799#comment-16862799
]
Feng Zhu commented on CALCITE-3060:
---
Hi, [~hyuan]. This issue is similar to the issue I found in CALCITE-3087. We
should fix the mapping beheavior.
{code:java}
query
==
Aggregate(groupSet: {0}, groupSets: [{0}], calls: [COUNT()])
Project(projects: [$0, $3])
Scan(table: [hr, emps])
target
==
Aggregate(groupSet: {0}, groupSets: [{0}], calls: [MIN($1), COUNT(), MAX($1),
SUM($1)])
Project(projects: [$0, $3])
Scan(table: [hr, emps]){code}
When _unifyAggregate(query, target)_, a MutableProject will be generated.
{code:java}
MutableRels.createProject(target, projects)
//empid ($0), count($2)
projects = [0, 2]
// call MutableRels.createProject
Mappings.bijection(projects{code}
However, the posList is not always a bijection mapping. We should use
*INVERSE_SURJECTION* mapping, as that in RelFieldTrimmer.
> Materialized view: "target out of range" error
> --
>
> Key: CALCITE-3060
> URL: https://issues.apache.org/jira/browse/CALCITE-3060
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.19.0
>Reporter: Anton Haidai
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> "MaterializationTest":
> {code}
> @Test public void testPermutationError() {
> CalciteAssert.that()
> .withMaterializations(
> HR_FKUK_MODEL,
> "m0",
> "select min(\"salary\"), count(*), max(\"salary\"),
> sum(\"salary\"), \"empid\" from \"emps\" group by \"empid\"",
> "m1",
> "select min(\"salary\"), count(*), max(\"salary\"),
> sum(\"salary\"), \"deptno\", \"empid\" from \"emps\" group by \"empid\",
> \"deptno\""
> )
> .query(
> "select count(*), \"empid\" from \"emps\" group by \"empid\"")
> .enableMaterializations(true)
> .explainContains("EnumerableTableScan(table=[[hr, m0]])")
> .sameResultWithMaterializationsDisabled();
> }
> {code}
> Error (looks like the mapping is expected to be bijection but it is not):
> {code}
> Caused by: java.lang.IllegalArgumentException: target out of range
> at org.apache.calcite.util.Permutation.(Permutation.java:69)
> at org.apache.calcite.util.mapping.Mappings.bijection(Mappings.java:394)
> at
> org.apache.calcite.rel.mutable.MutableRels.createProject(MutableRels.java:142)
> at
> org.apache.calcite.plan.SubstitutionVisitor.unifyAggregates(SubstitutionVisitor.java:1269)
> at
> org.apache.calcite.plan.SubstitutionVisitor$AggregateOnProjectToAggregateUnifyRule.apply(SubstitutionVisitor.java:1345)
> at
> org.apache.calcite.plan.SubstitutionVisitor.go(SubstitutionVisitor.java:531)
> at
> org.apache.calcite.plan.SubstitutionVisitor.go(SubstitutionVisitor.java:466)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2995) Add the DAYNAME，MONTHNAME function
[
https://issues.apache.org/jira/browse/CALCITE-2995?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16862780#comment-16862780
]
Forward Xu commented on CALCITE-2995:
-
hi [~julianhyde] well ，Thank you very much，You made me learn a lot.I have no
other opinions, you can merge it.
> Add the DAYNAME，MONTHNAME function
> --
>
> Key: CALCITE-2995
> URL: https://issues.apache.org/jira/browse/CALCITE-2995
> Project: Calcite
> Issue Type: New Feature
>Reporter: Forward Xu
>Assignee: Forward Xu
>Priority: Major
> Labels: pull-request-available
> Time Spent: 4h
> Remaining Estimate: 0h
>
> MONTHNAME(date)
> Returns the full name of the month for date. The language used for the name
> is controlled by the system time config.
> SQL:
> {code:java}
> SELECT MONTHNAME('2018-01-01') monthname;{code}
> Result:
> ||monthname||
> |January|
> DAYNAME(date)
> Returns the name of the weekday for date. The language used for the name is
> controlled by the system time config.
> SQL:
> {code:java}
> SELECT DAYNAME('2018-01-01') dayname;{code}
> Result:
> ||dayname||
> |Monday|
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2995) Add the DAYNAME，MONTHNAME function
[
https://issues.apache.org/jira/browse/CALCITE-2995?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16862771#comment-16862771
]
Julian Hyde commented on CALCITE-2995:
--
I still think that the default locale should be root. If people want a
different locale, they can set it. The difference in day and month names
between JDK 8 and 9 makes it a little tricky to test, but it won't be too
noticeable to users.
Please take a look at my revisions:
https://github.com/julianhyde/calcite/commit/b7f4cbdd396088d4b448895d45f6392d150c6d4d.
If you approve I'll squash and merge to master.
> Add the DAYNAME，MONTHNAME function
> --
>
> Key: CALCITE-2995
> URL: https://issues.apache.org/jira/browse/CALCITE-2995
> Project: Calcite
> Issue Type: New Feature
>Reporter: Forward Xu
>Assignee: Forward Xu
>Priority: Major
> Labels: pull-request-available
> Time Spent: 4h
> Remaining Estimate: 0h
>
> MONTHNAME(date)
> Returns the full name of the month for date. The language used for the name
> is controlled by the system time config.
> SQL:
> {code:java}
> SELECT MONTHNAME('2018-01-01') monthname;{code}
> Result:
> ||monthname||
> |January|
> DAYNAME(date)
> Returns the name of the weekday for date. The language used for the name is
> controlled by the system time config.
> SQL:
> {code:java}
> SELECT DAYNAME('2018-01-01') dayname;{code}
> Result:
> ||dayname||
> |Monday|
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
