[jira] [Commented] (CALCITE-3741) duplicate ‘ordre by‘ key word generate in select
[ https://issues.apache.org/jira/browse/CALCITE-3741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17017763#comment-17017763 ] Danny Chen commented on CALCITE-3741: - Take this PR https://github.com/apache/calcite/commit/fe0a2fe7dde4a4a342cfc50f2f9da983cc60c479 for a reference to see how to fix the sort. > duplicate ‘ordre by‘ key word generate in select > > > Key: CALCITE-3741 > URL: https://issues.apache.org/jira/browse/CALCITE-3741 > Project: Calcite > Issue Type: Bug > Components: mongodb-adapter >Affects Versions: 1.17.0 >Reporter: james601232 >Priority: Major > Attachments: image-2020-01-16-14-28-57-662.png, > image-2020-01-17-09-40-47-906.png, image-2020-01-17-10-43-28-765.png > > > Hi > I encoutner a problem use calcite query mongodb. my select sql is "select > * from products order by score". unfortunatly. calcite analysis sql concat > redundant 'order by score' in sql. > debug screenshot as following: > !image-2020-01-16-14-28-57-662.png! > could you help me what wrong happen. > Tks > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-3731) Add IF function for BigQuery, Hive and Spark Dialects
[ https://issues.apache.org/jira/browse/CALCITE-3731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17017760#comment-17017760 ] Stamatis Zampetakis commented on CALCITE-3731: -- Such conversions are done via [StandardConvertletTable|https://github.com/apache/calcite/blob/b1c7a0be86498d4c7688c28191416e9a57a17275/core/src/main/java/org/apache/calcite/sql2rel/StandardConvertletTable.java#L141]. > Add IF function for BigQuery, Hive and Spark Dialects > - > > Key: CALCITE-3731 > URL: https://issues.apache.org/jira/browse/CALCITE-3731 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: vaibhav jain >Priority: Major > Labels: pull-request-available > Time Spent: 3h 20m > Remaining Estimate: 0h > > Adding support for *IF* function for BigQuery, Hive and Spark Dialects. > *Syntax*- IF(condition, true_result, false_result) > If *condition* is true, returns *true_result*, else returns *false_result*. > Document links: > [BigQuery|https://cloud.google.com/bigquery/docs/reference/standard-sql/conditional_expressions] > [Hive > |https://cwiki.apache.org/confluence/display/Hive/LanguageManual+UDF#LanguageManualUDF-ConditionalFunctions] > [Spark Sql|https://spark.apache.org/docs/2.3.1/api/sql/index.html#if] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (CALCITE-3743) Implement PERCENT_RANK window aggregate function
[
https://issues.apache.org/jira/browse/CALCITE-3743?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rui Wang closed CALCITE-3743.
-
Resolution: Duplicate
> Implement PERCENT_RANK window aggregate function
>
>
> Key: CALCITE-3743
> URL: https://issues.apache.org/jira/browse/CALCITE-3743
> Project: Calcite
> Issue Type: Bug
>Reporter: Rui Wang
>Assignee: Rui Wang
>Priority: Major
>
> It seems like Calcite does not have an implementation of PERCENT_RANK: see
> the list of implemented window aggregate function:
> https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/adapter/enumerable/RexImpTable.java#L635
> Did a quick check and MySQL, Postgresql, Oracle, BigQuery all support it. The
> definition is consistent:
> {code:java}
> the function returns relative rank of the current row: (rank - 1) / (total
> partition rows - 1)
> {code}
> The return value should be double.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-3743) Implement PERCENT_RANK window aggregate function
[
https://issues.apache.org/jira/browse/CALCITE-3743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17017709#comment-17017709
]
Rui Wang commented on CALCITE-3743:
---
Thanks [~donnyzone]. Will close this Jira.
> Implement PERCENT_RANK window aggregate function
>
>
> Key: CALCITE-3743
> URL: https://issues.apache.org/jira/browse/CALCITE-3743
> Project: Calcite
> Issue Type: Bug
>Reporter: Rui Wang
>Assignee: Rui Wang
>Priority: Major
>
> It seems like Calcite does not have an implementation of PERCENT_RANK: see
> the list of implemented window aggregate function:
> https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/adapter/enumerable/RexImpTable.java#L635
> Did a quick check and MySQL, Postgresql, Oracle, BigQuery all support it. The
> definition is consistent:
> {code:java}
> the function returns relative rank of the current row: (rank - 1) / (total
> partition rows - 1)
> {code}
> The return value should be double.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-3741) duplicate ‘ordre by‘ key word generate in select
[ https://issues.apache.org/jira/browse/CALCITE-3741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17017679#comment-17017679 ] james601232 commented on CALCITE-3741: -- Dear [~danny0405] yes. ur right. could you give me a temporary soulation fixed the order by issue not upgrade calcite version. for us upgrade calcite is a very large project. > duplicate ‘ordre by‘ key word generate in select > > > Key: CALCITE-3741 > URL: https://issues.apache.org/jira/browse/CALCITE-3741 > Project: Calcite > Issue Type: Bug > Components: mongodb-adapter >Affects Versions: 1.17.0 >Reporter: james601232 >Priority: Major > Attachments: image-2020-01-16-14-28-57-662.png, > image-2020-01-17-09-40-47-906.png, image-2020-01-17-10-43-28-765.png > > > Hi > I encoutner a problem use calcite query mongodb. my select sql is "select > * from products order by score". unfortunatly. calcite analysis sql concat > redundant 'order by score' in sql. > debug screenshot as following: > !image-2020-01-16-14-28-57-662.png! > could you help me what wrong happen. > Tks > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-3741) duplicate ‘ordre by‘ key word generate in select
[ https://issues.apache.org/jira/browse/CALCITE-3741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17017676#comment-17017676 ] Danny Chen commented on CALCITE-3741: - I kind of know what happens, it is not the SqlParser, but the RelToSqlConverter that outputs the error SQL, can you try the latest code branch instead of 1.17.0 ? We made some promotion for Jdbc sort unparse recently. > duplicate ‘ordre by‘ key word generate in select > > > Key: CALCITE-3741 > URL: https://issues.apache.org/jira/browse/CALCITE-3741 > Project: Calcite > Issue Type: Bug > Components: mongodb-adapter >Affects Versions: 1.17.0 >Reporter: james601232 >Priority: Major > Attachments: image-2020-01-16-14-28-57-662.png, > image-2020-01-17-09-40-47-906.png, image-2020-01-17-10-43-28-765.png > > > Hi > I encoutner a problem use calcite query mongodb. my select sql is "select > * from products order by score". unfortunatly. calcite analysis sql concat > redundant 'order by score' in sql. > debug screenshot as following: > !image-2020-01-16-14-28-57-662.png! > could you help me what wrong happen. > Tks > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-3741) duplicate ‘ordre by‘ key word generate in select
[
https://issues.apache.org/jira/browse/CALCITE-3741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17017668#comment-17017668
]
james601232 commented on CALCITE-3741:
--
Dear [~icshuo]
type sql is "select * from products {color:#ff}order by
score{color}". but debug pic show two order by score words in
{color:#de350b}node{color} and {color:#de350b}orderBy{color} struct.
why node and orderBy have more than one order by score word. do it normally?
!image-2020-01-17-10-43-28-765.png!
> duplicate ‘ordre by‘ key word generate in select
>
>
> Key: CALCITE-3741
> URL: https://issues.apache.org/jira/browse/CALCITE-3741
> Project: Calcite
> Issue Type: Bug
> Components: mongodb-adapter
>Affects Versions: 1.17.0
>Reporter: james601232
>Priority: Major
> Attachments: image-2020-01-16-14-28-57-662.png,
> image-2020-01-17-09-40-47-906.png, image-2020-01-17-10-43-28-765.png
>
>
> Hi
> I encoutner a problem use calcite query mongodb. my select sql is "select
> * from products order by score". unfortunatly. calcite analysis sql concat
> redundant 'order by score' in sql.
> debug screenshot as following:
> !image-2020-01-16-14-28-57-662.png!
> could you help me what wrong happen.
> Tks
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-3741) duplicate ‘ordre by‘ key word generate in select
[ https://issues.apache.org/jira/browse/CALCITE-3741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] james601232 updated CALCITE-3741: - Attachment: image-2020-01-17-10-43-28-765.png > duplicate ‘ordre by‘ key word generate in select > > > Key: CALCITE-3741 > URL: https://issues.apache.org/jira/browse/CALCITE-3741 > Project: Calcite > Issue Type: Bug > Components: mongodb-adapter >Affects Versions: 1.17.0 >Reporter: james601232 >Priority: Major > Attachments: image-2020-01-16-14-28-57-662.png, > image-2020-01-17-09-40-47-906.png, image-2020-01-17-10-43-28-765.png > > > Hi > I encoutner a problem use calcite query mongodb. my select sql is "select > * from products order by score". unfortunatly. calcite analysis sql concat > redundant 'order by score' in sql. > debug screenshot as following: > !image-2020-01-16-14-28-57-662.png! > could you help me what wrong happen. > Tks > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-3743) Implement PERCENT_RANK window aggregate function
[
https://issues.apache.org/jira/browse/CALCITE-3743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17017667#comment-17017667
]
Feng Zhu commented on CALCITE-3743:
---
It duplicates with CALCITE-2414.
> Implement PERCENT_RANK window aggregate function
>
>
> Key: CALCITE-3743
> URL: https://issues.apache.org/jira/browse/CALCITE-3743
> Project: Calcite
> Issue Type: Bug
>Reporter: Rui Wang
>Assignee: Rui Wang
>Priority: Major
>
> It seems like Calcite does not have an implementation of PERCENT_RANK: see
> the list of implemented window aggregate function:
> https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/adapter/enumerable/RexImpTable.java#L635
> Did a quick check and MySQL, Postgresql, Oracle, BigQuery all support it. The
> definition is consistent:
> {code:java}
> the function returns relative rank of the current row: (rank - 1) / (total
> partition rows - 1)
> {code}
> The return value should be double.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-3741) duplicate ‘ordre by‘ key word generate in select
[ https://issues.apache.org/jira/browse/CALCITE-3741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17017651#comment-17017651 ] Shuo Cheng commented on CALCITE-3741: - Hi, James, it would be more clear if you can just paste the original *test case* rather than the debugging pics. > duplicate ‘ordre by‘ key word generate in select > > > Key: CALCITE-3741 > URL: https://issues.apache.org/jira/browse/CALCITE-3741 > Project: Calcite > Issue Type: Bug > Components: mongodb-adapter >Affects Versions: 1.17.0 >Reporter: james601232 >Priority: Major > Attachments: image-2020-01-16-14-28-57-662.png, > image-2020-01-17-09-40-47-906.png > > > Hi > I encoutner a problem use calcite query mongodb. my select sql is "select > * from products order by score". unfortunatly. calcite analysis sql concat > redundant 'order by score' in sql. > debug screenshot as following: > !image-2020-01-16-14-28-57-662.png! > could you help me what wrong happen. > Tks > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-3732) Implement bit functions and operators
[ https://issues.apache.org/jira/browse/CALCITE-3732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17017640#comment-17017640 ] Julian Hyde commented on CALCITE-3732: -- I'm not sure Oracle has all of those functions in SQL. The ones you list are in PL/SQL. I would not implement those. BIT_AND, BIT_OR etc. are aggregate functions. What do you propose to call the binary non-aggregate functions that perform bitwise and, or, etc.? > Implement bit functions and operators > - > > Key: CALCITE-3732 > URL: https://issues.apache.org/jira/browse/CALCITE-3732 > Project: Calcite > Issue Type: Improvement > Components: core >Affects Versions: 1.21.0 >Reporter: hailong wang >Assignee: hailong wang >Priority: Major > Fix For: 1.22.0 > > > Bit function is non-standard operators, but all db has implemented, such as > mysql, postgresql. > Calcite has implemented BIT_AND, BIT_OR in > https://issues.apache.org/jira/browse/CALCITE-2770, BIT_XOR in > https://issues.apache.org/jira/browse/CALCITE-3591. BIT_COUNT is in progress > https://issues.apache.org/jira/browse/CALCITE-3697, BIT_NOT(~) is in progress > https://issues.apache.org/jira/browse/CALCITE-3592. > So I think we should also implement Bitwise AND(&), Right shift(>>), Left > shift(<<), Bitwise XOR(^), Bitwise OR(|). And data types support tinyint, > smallint, int, bigint like before. > > Refence: > [https://dev.mysql.com/doc/refman/8.0/en/bit-functions.html#operator_bitwise-invert] > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-3741) duplicate ‘ordre by‘ key word generate in select
[
https://issues.apache.org/jira/browse/CALCITE-3741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17017638#comment-17017638
]
james601232 commented on CALCITE-3741:
--
Dear [~amaliujia]
we have a open project quicksql. it's use jdbc:calcite method query
mongodb. type sql "select * from products order by score". calcite analysis and
optimistc the sql found more than one “order by score” key word in sql. eg.
“select * from products {color:#FF}order by score order by score{color}”
{color:#172b4d}. I tried debug codes and found SqlValidatorImpl class deal
order by logic. but i don't known how to cope it. hopeful getting help. thank
u so much {color}
{color:#172b4d}!image-2020-01-17-09-40-47-906.png!{color}
> duplicate ‘ordre by‘ key word generate in select
>
>
> Key: CALCITE-3741
> URL: https://issues.apache.org/jira/browse/CALCITE-3741
> Project: Calcite
> Issue Type: Bug
> Components: mongodb-adapter
>Affects Versions: 1.17.0
>Reporter: james601232
>Priority: Major
> Attachments: image-2020-01-16-14-28-57-662.png,
> image-2020-01-17-09-40-47-906.png
>
>
> Hi
> I encoutner a problem use calcite query mongodb. my select sql is "select
> * from products order by score". unfortunatly. calcite analysis sql concat
> redundant 'order by score' in sql.
> debug screenshot as following:
> !image-2020-01-16-14-28-57-662.png!
> could you help me what wrong happen.
> Tks
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-3741) duplicate ‘ordre by‘ key word generate in select
[ https://issues.apache.org/jira/browse/CALCITE-3741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] james601232 updated CALCITE-3741: - Attachment: image-2020-01-17-09-40-47-906.png > duplicate ‘ordre by‘ key word generate in select > > > Key: CALCITE-3741 > URL: https://issues.apache.org/jira/browse/CALCITE-3741 > Project: Calcite > Issue Type: Bug > Components: mongodb-adapter >Affects Versions: 1.17.0 >Reporter: james601232 >Priority: Major > Attachments: image-2020-01-16-14-28-57-662.png, > image-2020-01-17-09-40-47-906.png > > > Hi > I encoutner a problem use calcite query mongodb. my select sql is "select > * from products order by score". unfortunatly. calcite analysis sql concat > redundant 'order by score' in sql. > debug screenshot as following: > !image-2020-01-16-14-28-57-662.png! > could you help me what wrong happen. > Tks > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Issue Comment Deleted] (CALCITE-3741) duplicate ‘ordre by‘ key word generate in select
[ https://issues.apache.org/jira/browse/CALCITE-3741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] james601232 updated CALCITE-3741: - Comment: was deleted (was: Dear [~amaliujia]) > duplicate ‘ordre by‘ key word generate in select > > > Key: CALCITE-3741 > URL: https://issues.apache.org/jira/browse/CALCITE-3741 > Project: Calcite > Issue Type: Bug > Components: mongodb-adapter >Affects Versions: 1.17.0 >Reporter: james601232 >Priority: Major > Attachments: image-2020-01-16-14-28-57-662.png > > > Hi > I encoutner a problem use calcite query mongodb. my select sql is "select > * from products order by score". unfortunatly. calcite analysis sql concat > redundant 'order by score' in sql. > debug screenshot as following: > !image-2020-01-16-14-28-57-662.png! > could you help me what wrong happen. > Tks > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-3741) duplicate ‘ordre by‘ key word generate in select
[ https://issues.apache.org/jira/browse/CALCITE-3741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17017630#comment-17017630 ] james601232 commented on CALCITE-3741: -- Dear [~amaliujia] > duplicate ‘ordre by‘ key word generate in select > > > Key: CALCITE-3741 > URL: https://issues.apache.org/jira/browse/CALCITE-3741 > Project: Calcite > Issue Type: Bug > Components: mongodb-adapter >Affects Versions: 1.17.0 >Reporter: james601232 >Priority: Major > Attachments: image-2020-01-16-14-28-57-662.png > > > Hi > I encoutner a problem use calcite query mongodb. my select sql is "select > * from products order by score". unfortunatly. calcite analysis sql concat > redundant 'order by score' in sql. > debug screenshot as following: > !image-2020-01-16-14-28-57-662.png! > could you help me what wrong happen. > Tks > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-3741) duplicate ‘ordre by‘ key word generate in select
[ https://issues.apache.org/jira/browse/CALCITE-3741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17017631#comment-17017631 ] james601232 commented on CALCITE-3741: -- Dear [~amaliujia] > duplicate ‘ordre by‘ key word generate in select > > > Key: CALCITE-3741 > URL: https://issues.apache.org/jira/browse/CALCITE-3741 > Project: Calcite > Issue Type: Bug > Components: mongodb-adapter >Affects Versions: 1.17.0 >Reporter: james601232 >Priority: Major > Attachments: image-2020-01-16-14-28-57-662.png > > > Hi > I encoutner a problem use calcite query mongodb. my select sql is "select > * from products order by score". unfortunatly. calcite analysis sql concat > redundant 'order by score' in sql. > debug screenshot as following: > !image-2020-01-16-14-28-57-662.png! > could you help me what wrong happen. > Tks > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Issue Comment Deleted] (CALCITE-3741) duplicate ‘ordre by‘ key word generate in select
[ https://issues.apache.org/jira/browse/CALCITE-3741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] james601232 updated CALCITE-3741: - Comment: was deleted (was: Dear [~amaliujia] ) > duplicate ‘ordre by‘ key word generate in select > > > Key: CALCITE-3741 > URL: https://issues.apache.org/jira/browse/CALCITE-3741 > Project: Calcite > Issue Type: Bug > Components: mongodb-adapter >Affects Versions: 1.17.0 >Reporter: james601232 >Priority: Major > Attachments: image-2020-01-16-14-28-57-662.png > > > Hi > I encoutner a problem use calcite query mongodb. my select sql is "select > * from products order by score". unfortunatly. calcite analysis sql concat > redundant 'order by score' in sql. > debug screenshot as following: > !image-2020-01-16-14-28-57-662.png! > could you help me what wrong happen. > Tks > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-3721) Filter of distinct aggregate call is lost after applying `AggregateExpandDistinctAggregatesRule`
[
https://issues.apache.org/jira/browse/CALCITE-3721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17017624#comment-17017624
]
Danny Chen commented on CALCITE-3721:
-
bq. filters tend to behave similarly to arguments to aggregate functions, and
maybe you can exploit that
With both distinct/non-distinct agg calls mixed in one aggregate, i couldn't
figure out how a common filter can be applied, i prefer the original to output
a filter flag.
bq. You say that you 'remove useless exprs in projects'; did that add
significant complexity?
Not really, just need to add another "if" decision when generating the boolean
flag.
> Filter of distinct aggregate call is lost after applying
> `AggregateExpandDistinctAggregatesRule`
>
>
> Key: CALCITE-3721
> URL: https://issues.apache.org/jira/browse/CALCITE-3721
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.21.0
>Reporter: Shuo Cheng
>Assignee: Shuo Cheng
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.22.0
>
> Time Spent: 3h 20m
> Remaining Estimate: 0h
>
> In `AggregateExpandDistinctAggregatesRule`, when the distinct aggregate call
> is rewritten using
> groupingSets, the filter of the distinct aggregate call itself is lost
> unexpected.
> Currently, the plan of the following sql after applying
> `AggregateExpandDistinctAggregatesRule` is :
> {code:java}
> // SQL
> SELECT
>SUM(comm), COUNT(DISTINCT sal) FILTER (WHERE sal > 1000)
> FROM emp{code}
> {color:#de350b}current plan is:{color}
> {code:java}
> LogicalAggregate(group=[{}], EXPR$0=[MIN($2) FILTER $4], EXPR$1=[COUNT($0)
> FILTER $3])
> LogicalProject(SAL=[$0], $f2=[$1], EXPR$0=[$2], $g_0=[=($3, 0)],
> $g_3=[=($3, 3)])
> LogicalAggregate(group=[{1, 2}], groups=[[{1, 2}, {}]], EXPR$0=[SUM($0)],
> $g=[GROUPING($1, $2)])
> LogicalProject(COMM=[$6], SAL=[$5], $f2=[>($5, 1000)])
> LogicalTableScan(table=[[CATALOG, SALES, EMP]]){code}
> But actually, the {color:#4c9aff}expected or correct plan{color} is:
> {code:java}
> LogicalAggregate(group=[{}], EXPR$0=[MIN($2) FILTER $4], EXPR$1=[COUNT($0)
> FILTER $3])
> LogicalProject(SAL=[$0], $f2=[$1], EXPR$0=[$2], $g_0=[AND(=($3, 0), IS
> TRUE($1))], $g_3=[=($3, 3)])
> LogicalAggregate(group=[{1, 2}], groups=[[{1, 2}, {}]], EXPR$0=[SUM($0)],
> $g=[GROUPING($1, $2)])
> LogicalProject(COMM=[$6], SAL=[$5], $f2=[>($5, 1000)])
> LogicalTableScan(table=[[CATALOG, SALES, EMP]]){code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (CALCITE-3744) Duplicate RuleMatches when RelSet gets merged
Haisheng Yuan created CALCITE-3744:
--
Summary: Duplicate RuleMatches when RelSet gets merged
Key: CALCITE-3744
URL: https://issues.apache.org/jira/browse/CALCITE-3744
Project: Calcite
Issue Type: Bug
Components: core
Reporter: Haisheng Yuan
Some times RelSet can get merged. e.g.
Each number represet Rel id, and they are in different RelSet.
{code:java}
14
\ /
2 /
\/
3
{code}
Assume in the rulequeue, we have rule match with name of 12, 23, 43. For
simplicity, omit the rule name, first digit represent the parent RelNode,
second represent the child.
If after some rule, we merged the set of 3 into the set of 2, and RelNode 4's
input is replaced by RelSubset of 2. We will retrigger rules and try to add
rulematch 12, 42, 43 into rule queue.
12 will be filtered out, because there is duplicate in the RuleMatch names set.
But for 43, it now has different rulematch digest with previous match, because
RelNode #4's input RelSubset changed, its digest also changed. So we can't
detect the duplication and will re-apply rulematch 43 twice.
Although we try to recompute rulematch's digest when popMatch(), but it seems
too late.
I think in RuleMatch digest, just using relnode's id should suffice. And we
don't need to call recomputeDigest when popMatch.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-3743) Implement PERCENT_RANK window aggregate function
[
https://issues.apache.org/jira/browse/CALCITE-3743?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rui Wang updated CALCITE-3743:
--
Summary: Implement PERCENT_RANK window aggregate function (was: Support
PERCENT_RANK window aggregate function)
> Implement PERCENT_RANK window aggregate function
>
>
> Key: CALCITE-3743
> URL: https://issues.apache.org/jira/browse/CALCITE-3743
> Project: Calcite
> Issue Type: Bug
>Reporter: Rui Wang
>Assignee: Rui Wang
>Priority: Major
>
> It seems like Calcite does not have an implementation of PERCENT_RANK: see
> the list of implemented window aggregate function:
> https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/adapter/enumerable/RexImpTable.java#L635
> Did a quick check and MySQL, Postgresql, Oracle, BigQuery all support it. The
> definition is consistent:
> {code:java}
> the function returns relative rank of the current row: (rank - 1) / (total
> partition rows - 1)
> {code}
> The return value should be double.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-3743) Support PERCENT_RANK window aggregate function
[
https://issues.apache.org/jira/browse/CALCITE-3743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17017475#comment-17017475
]
Rui Wang commented on CALCITE-3743:
---
It turns out that Calcite supports percent_rank in parser (and there is an
operator that defines it). But the implementation of that function is the same
as Rank(). E,g, I duplicate a rank's test case but change the function call to
percent_rank, the result will be the same.
> Support PERCENT_RANK window aggregate function
> --
>
> Key: CALCITE-3743
> URL: https://issues.apache.org/jira/browse/CALCITE-3743
> Project: Calcite
> Issue Type: Bug
>Reporter: Rui Wang
>Assignee: Rui Wang
>Priority: Major
>
> It seems like Calcite does not have an implementation of PERCENT_RANK: see
> the list of implemented window aggregate function:
> https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/adapter/enumerable/RexImpTable.java#L635
> Did a quick check and MySQL, Postgresql, Oracle, BigQuery all support it. The
> definition is consistent:
> {code:java}
> the function returns relative rank of the current row: (rank - 1) / (total
> partition rows - 1)
> {code}
> The return value should be double.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-3743) Support PERCENT_RANK window aggregate function
[
https://issues.apache.org/jira/browse/CALCITE-3743?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rui Wang updated CALCITE-3743:
--
Issue Type: Bug (was: Task)
> Support PERCENT_RANK window aggregate function
> --
>
> Key: CALCITE-3743
> URL: https://issues.apache.org/jira/browse/CALCITE-3743
> Project: Calcite
> Issue Type: Bug
>Reporter: Rui Wang
>Assignee: Rui Wang
>Priority: Major
>
> It seems like Calcite does not have an implementation of PERCENT_RANK: see
> the list of implemented window aggregate function:
> https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/adapter/enumerable/RexImpTable.java#L635
> Did a quick check and MySQL, Postgresql, Oracle, BigQuery all support it. The
> definition is consistent:
> {code:java}
> the function returns relative rank of the current row: (rank - 1) / (total
> partition rows - 1)
> {code}
> The return value should be double.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (CALCITE-3743) Support PERCENT_RANK window aggregate function
[
https://issues.apache.org/jira/browse/CALCITE-3743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17017445#comment-17017445
]
Rui Wang edited comment on CALCITE-3743 at 1/16/20 8:17 PM:
Question: which class is the place to test such implementation?
---
update:
I found winagg.iq is a appropriate place.
was (Author: amaliujia):
Question: which class is the place to test such implementation?
> Support PERCENT_RANK window aggregate function
> --
>
> Key: CALCITE-3743
> URL: https://issues.apache.org/jira/browse/CALCITE-3743
> Project: Calcite
> Issue Type: Task
>Reporter: Rui Wang
>Assignee: Rui Wang
>Priority: Major
>
> It seems like Calcite does not have an implementation of PERCENT_RANK: see
> the list of implemented window aggregate function:
> https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/adapter/enumerable/RexImpTable.java#L635
> Did a quick check and MySQL, Postgresql, Oracle, BigQuery all support it. The
> definition is consistent:
> {code:java}
> the function returns relative rank of the current row: (rank - 1) / (total
> partition rows - 1)
> {code}
> The return value should be double.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-3743) Support PERCENT_RANK window aggregate function
[
https://issues.apache.org/jira/browse/CALCITE-3743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17017445#comment-17017445
]
Rui Wang commented on CALCITE-3743:
---
Question: which class is the place to test such implementation?
> Support PERCENT_RANK window aggregate function
> --
>
> Key: CALCITE-3743
> URL: https://issues.apache.org/jira/browse/CALCITE-3743
> Project: Calcite
> Issue Type: Task
>Reporter: Rui Wang
>Assignee: Rui Wang
>Priority: Major
>
> It seems like Calcite does not have an implementation of PERCENT_RANK: see
> the list of implemented window aggregate function:
> https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/adapter/enumerable/RexImpTable.java#L635
> Did a quick check and MySQL, Postgresql, Oracle, BigQuery all support it. The
> definition is consistent:
> {code:java}
> the function returns relative rank of the current row: (rank - 1) / (total
> partition rows - 1)
> {code}
> The return value should be double.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-3743) Support PERCENT_RANK window aggregate function
[
https://issues.apache.org/jira/browse/CALCITE-3743?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rui Wang updated CALCITE-3743:
--
Description:
It seems like Calcite does not have an implementation of PERCENT_RANK: see the
list of implemented window aggregate function:
https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/adapter/enumerable/RexImpTable.java#L635
Did a quick check and MySQL, Postgresql, Oracle, BigQuery all support it. The
definition is consistent:
{code:java}
the function returns relative rank of the current row: (rank - 1) / (total
partition rows - 1)
{code}
The return value should be double.
was:
It seems like Calcite does not have an implementation of PERCENT_RANK: see the
list of implemented window aggregate function:
https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/adapter/enumerable/RexImpTable.java#L635
Did a quick check and MySQL, Postgresql, Oracle, BigQuery all support it. The
definition is consistent:
the function returns relative rank of the current row: (rank - 1) / (total
partition rows - 1)
The return value should be double.
> Support PERCENT_RANK window aggregate function
> --
>
> Key: CALCITE-3743
> URL: https://issues.apache.org/jira/browse/CALCITE-3743
> Project: Calcite
> Issue Type: Task
>Reporter: Rui Wang
>Assignee: Rui Wang
>Priority: Major
>
> It seems like Calcite does not have an implementation of PERCENT_RANK: see
> the list of implemented window aggregate function:
> https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/adapter/enumerable/RexImpTable.java#L635
> Did a quick check and MySQL, Postgresql, Oracle, BigQuery all support it. The
> definition is consistent:
> {code:java}
> the function returns relative rank of the current row: (rank - 1) / (total
> partition rows - 1)
> {code}
> The return value should be double.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (CALCITE-3743) Support PERCENT_RANK window aggregate function
Rui Wang created CALCITE-3743: - Summary: Support PERCENT_RANK window aggregate function Key: CALCITE-3743 URL: https://issues.apache.org/jira/browse/CALCITE-3743 Project: Calcite Issue Type: Task Reporter: Rui Wang Assignee: Rui Wang It seems like Calcite does not have an implementation of PERCENT_RANK: see the list of implemented window aggregate function: https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/adapter/enumerable/RexImpTable.java#L635 Did a quick check and MySQL, Postgresql, Oracle, BigQuery all support it. The definition is consistent: the function returns relative rank of the current row: (rank - 1) / (total partition rows - 1) The return value should be double. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-3721) Filter of distinct aggregate call is lost after applying `AggregateExpandDistinctAggregatesRule`
[
https://issues.apache.org/jira/browse/CALCITE-3721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17017416#comment-17017416
]
Julian Hyde commented on CALCITE-3721:
--
The fix adds a lot more complexity than I had been expecting. Are there any
tricks you missed? For example, RelBuilder is pretty good at creating filters
from RexNode expressions; filters tend to behave similarly to arguments to
aggregate functions, and maybe you can exploit that.
You say that you 'remove useless exprs in projects'; did that add significant
complexity?
> Filter of distinct aggregate call is lost after applying
> `AggregateExpandDistinctAggregatesRule`
>
>
> Key: CALCITE-3721
> URL: https://issues.apache.org/jira/browse/CALCITE-3721
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.21.0
>Reporter: Shuo Cheng
>Assignee: Shuo Cheng
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.22.0
>
> Time Spent: 3h 20m
> Remaining Estimate: 0h
>
> In `AggregateExpandDistinctAggregatesRule`, when the distinct aggregate call
> is rewritten using
> groupingSets, the filter of the distinct aggregate call itself is lost
> unexpected.
> Currently, the plan of the following sql after applying
> `AggregateExpandDistinctAggregatesRule` is :
> {code:java}
> // SQL
> SELECT
>SUM(comm), COUNT(DISTINCT sal) FILTER (WHERE sal > 1000)
> FROM emp{code}
> {color:#de350b}current plan is:{color}
> {code:java}
> LogicalAggregate(group=[{}], EXPR$0=[MIN($2) FILTER $4], EXPR$1=[COUNT($0)
> FILTER $3])
> LogicalProject(SAL=[$0], $f2=[$1], EXPR$0=[$2], $g_0=[=($3, 0)],
> $g_3=[=($3, 3)])
> LogicalAggregate(group=[{1, 2}], groups=[[{1, 2}, {}]], EXPR$0=[SUM($0)],
> $g=[GROUPING($1, $2)])
> LogicalProject(COMM=[$6], SAL=[$5], $f2=[>($5, 1000)])
> LogicalTableScan(table=[[CATALOG, SALES, EMP]]){code}
> But actually, the {color:#4c9aff}expected or correct plan{color} is:
> {code:java}
> LogicalAggregate(group=[{}], EXPR$0=[MIN($2) FILTER $4], EXPR$1=[COUNT($0)
> FILTER $3])
> LogicalProject(SAL=[$0], $f2=[$1], EXPR$0=[$2], $g_0=[AND(=($3, 0), IS
> TRUE($1))], $g_3=[=($3, 3)])
> LogicalAggregate(group=[{1, 2}], groups=[[{1, 2}, {}]], EXPR$0=[SUM($0)],
> $g=[GROUPING($1, $2)])
> LogicalProject(COMM=[$6], SAL=[$5], $f2=[>($5, 1000)])
> LogicalTableScan(table=[[CATALOG, SALES, EMP]]){code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-3738) Missing LogicalSort for Insert statement
[
https://issues.apache.org/jira/browse/CALCITE-3738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17017399#comment-17017399
]
Haisheng Yuan commented on CALCITE-3738:
Now I think it may not harm to keep ordering. [~julianhyde] What do you think?
Can we keep the order?
> Missing LogicalSort for Insert statement
>
>
> Key: CALCITE-3738
> URL: https://issues.apache.org/jira/browse/CALCITE-3738
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.19.0
>Reporter: pengzhiwei
>Assignee: pengzhiwei
>Priority: Major
> Labels: pull-request-available
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> The following sql statement generates a wrong logical plan which missing the
> LogicalSort :
> {code:java}
> insert into t select id*10,name from users order by name;{code}
> the plan is :
> {code:java}
> LogicalTableModify(table=[[t]], operation=[INSERT], flattened=[false])
> LogicalProject(id=[*($0, 10)], name=[$1])
> LogicalTableScan(table=[[users]])
> {code}
> This issue is introduced by the issue
> https://issues.apache.org/jira/browse/CALCITE-2978
> which removes the sort by in sub-query.However the query in insert statement
> is not a sub-query.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-3741) duplicate ‘ordre by‘ key word generate in select
[ https://issues.apache.org/jira/browse/CALCITE-3741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17017365#comment-17017365 ] Rui Wang commented on CALCITE-3741: --- [~james601232] it could be very helpful if you share your test case. > duplicate ‘ordre by‘ key word generate in select > > > Key: CALCITE-3741 > URL: https://issues.apache.org/jira/browse/CALCITE-3741 > Project: Calcite > Issue Type: Bug > Components: mongodb-adapter >Affects Versions: 1.17.0 >Reporter: james601232 >Priority: Major > Attachments: image-2020-01-16-14-28-57-662.png > > > Hi > I encoutner a problem use calcite query mongodb. my select sql is "select > * from products order by score". unfortunatly. calcite analysis sql concat > redundant 'order by score' in sql. > debug screenshot as following: > !image-2020-01-16-14-28-57-662.png! > could you help me what wrong happen. > Tks > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-3738) Missing LogicalSort for Insert statement
[
https://issues.apache.org/jira/browse/CALCITE-3738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17017362#comment-17017362
]
Rui Wang commented on CALCITE-3738:
---
Move some discussions from PR to this thread:
I understand [~pzw2018]'s idea. Basically in some engine implementations (e.g.
big data related). It could insert into message queue or log file, in such that
an order could be preserved. Later when the generated data is consumed somehow
(e.g. someone writes a script to process log files), the ordering could be a
property to be used for optimization (e.g. don't sort again).
[~hyuan] suggests the consumer should sort it rather than assuming INSERT INTO
ORDER BY will perverse order. I also think it makes sense as it is what
relational algebra says about a table.
So I don't have a strong opinion to keep the LogicalSort now. If we keep it, it
could be useful in practice. But if we don't keep it, nothing is wrong.
> Missing LogicalSort for Insert statement
>
>
> Key: CALCITE-3738
> URL: https://issues.apache.org/jira/browse/CALCITE-3738
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.19.0
>Reporter: pengzhiwei
>Assignee: pengzhiwei
>Priority: Major
> Labels: pull-request-available
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> The following sql statement generates a wrong logical plan which missing the
> LogicalSort :
> {code:java}
> insert into t select id*10,name from users order by name;{code}
> the plan is :
> {code:java}
> LogicalTableModify(table=[[t]], operation=[INSERT], flattened=[false])
> LogicalProject(id=[*($0, 10)], name=[$1])
> LogicalTableScan(table=[[users]])
> {code}
> This issue is introduced by the issue
> https://issues.apache.org/jira/browse/CALCITE-2978
> which removes the sort by in sub-query.However the query in insert statement
> is not a sub-query.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (CALCITE-3731) Add IF function for BigQuery, Hive and Spark Dialects
[ https://issues.apache.org/jira/browse/CALCITE-3731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17017347#comment-17017347 ] Rui Wang edited comment on CALCITE-3731 at 1/16/20 5:50 PM: Agreed with all above. IF, CASE and Coalesce can all be converted to CASE WHEN and then share the same implementation. What can be investigated is if Calcite is doing such conversion. E.g. if you have a "IF" in parser, then in generated plan if it's converted to CASE. (I don't have an answer now) was (Author: amaliujia): Agreed with all above. IF, CASE and Coalesce can all be converted to CASE WHEN and then share the same implementation. > Add IF function for BigQuery, Hive and Spark Dialects > - > > Key: CALCITE-3731 > URL: https://issues.apache.org/jira/browse/CALCITE-3731 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: vaibhav jain >Priority: Major > Labels: pull-request-available > Time Spent: 3h 10m > Remaining Estimate: 0h > > Adding support for *IF* function for BigQuery, Hive and Spark Dialects. > *Syntax*- IF(condition, true_result, false_result) > If *condition* is true, returns *true_result*, else returns *false_result*. > Document links: > [BigQuery|https://cloud.google.com/bigquery/docs/reference/standard-sql/conditional_expressions] > [Hive > |https://cwiki.apache.org/confluence/display/Hive/LanguageManual+UDF#LanguageManualUDF-ConditionalFunctions] > [Spark Sql|https://spark.apache.org/docs/2.3.1/api/sql/index.html#if] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-3731) Add IF function for BigQuery, Hive and Spark Dialects
[ https://issues.apache.org/jira/browse/CALCITE-3731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17017347#comment-17017347 ] Rui Wang commented on CALCITE-3731: --- Agreed with all above. IF, CASE and Coalesce can all be converted to CASE and then share the same implementation. > Add IF function for BigQuery, Hive and Spark Dialects > - > > Key: CALCITE-3731 > URL: https://issues.apache.org/jira/browse/CALCITE-3731 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: vaibhav jain >Priority: Major > Labels: pull-request-available > Time Spent: 3h 10m > Remaining Estimate: 0h > > Adding support for *IF* function for BigQuery, Hive and Spark Dialects. > *Syntax*- IF(condition, true_result, false_result) > If *condition* is true, returns *true_result*, else returns *false_result*. > Document links: > [BigQuery|https://cloud.google.com/bigquery/docs/reference/standard-sql/conditional_expressions] > [Hive > |https://cwiki.apache.org/confluence/display/Hive/LanguageManual+UDF#LanguageManualUDF-ConditionalFunctions] > [Spark Sql|https://spark.apache.org/docs/2.3.1/api/sql/index.html#if] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (CALCITE-3731) Add IF function for BigQuery, Hive and Spark Dialects
[ https://issues.apache.org/jira/browse/CALCITE-3731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17017347#comment-17017347 ] Rui Wang edited comment on CALCITE-3731 at 1/16/20 5:48 PM: Agreed with all above. IF, CASE and Coalesce can all be converted to CASE WHEN and then share the same implementation. was (Author: amaliujia): Agreed with all above. IF, CASE and Coalesce can all be converted to CASE and then share the same implementation. > Add IF function for BigQuery, Hive and Spark Dialects > - > > Key: CALCITE-3731 > URL: https://issues.apache.org/jira/browse/CALCITE-3731 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: vaibhav jain >Priority: Major > Labels: pull-request-available > Time Spent: 3h 10m > Remaining Estimate: 0h > > Adding support for *IF* function for BigQuery, Hive and Spark Dialects. > *Syntax*- IF(condition, true_result, false_result) > If *condition* is true, returns *true_result*, else returns *false_result*. > Document links: > [BigQuery|https://cloud.google.com/bigquery/docs/reference/standard-sql/conditional_expressions] > [Hive > |https://cwiki.apache.org/confluence/display/Hive/LanguageManual+UDF#LanguageManualUDF-ConditionalFunctions] > [Spark Sql|https://spark.apache.org/docs/2.3.1/api/sql/index.html#if] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-3676) VolcanoPlanner. dumpGraphviz should handle exception gracefully
[
https://issues.apache.org/jira/browse/CALCITE-3676?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17017342#comment-17017342
]
Xiening Dai commented on CALCITE-3676:
--
Ok, that is a good workaround for now.
I am using our own modified Calcite version. May not be straightforward to
provide a repro step. I will see what I can do. Thanks.
> VolcanoPlanner. dumpGraphviz should handle exception gracefully
> ---
>
> Key: CALCITE-3676
> URL: https://issues.apache.org/jira/browse/CALCITE-3676
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Haisheng Yuan
>Assignee: Forward Xu
>Priority: Major
> Labels: pull-request-available
> Time Spent: 1h
> Remaining Estimate: 0h
>
> In case VolcanoPlanner can't generate plan due to some RelSubset doesn't have
> best rel, it will dump the sets and Graphviz. Since there is error during
> planning, we want to see the sets in the exception message, but when dumping
> Graphviz, it might encounter another exception (we can't guarantee all the
> sets and subsets are correctly generated for Graphviz), causing failure to
> dump Sets info, which is rather helpful in production system.
> {code:java}
> Caused by: java.lang.AssertionError
> at
> org.apache.calcite.util.PartiallyOrderedSet.findParentsChildren(PartiallyOrderedSet.java:318)
> at
> org.apache.calcite.util.PartiallyOrderedSet.findParents(PartiallyOrderedSet.java:308)
> at
> org.apache.calcite.util.PartiallyOrderedSet.add(PartiallyOrderedSet.java:226)
> at
> org.apache.calcite.plan.volcano.VolcanoPlanner.dumpGraphviz(VolcanoPlanner.java:1320)
> at
> org.apache.calcite.plan.volcano.VolcanoPlanner.dump(VolcanoPlanner.java:1194)
> at
> org.apache.calcite.plan.volcano.RelSubset$CheapestPlanReplacer.visit(RelSubset.java:606)
> at
> org.apache.calcite.plan.volcano.RelSubset.buildCheapestPlan(RelSubset.java:307)
> at
> org.apache.calcite.plan.volcano.VolcanoPlanner.findBestExp(VolcanoPlanner.java:649)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-3328) Immutable beans, powered by reflection
[
https://issues.apache.org/jira/browse/CALCITE-3328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17016907#comment-17016907
]
Vladimir Sitnikov commented on CALCITE-3328:
[~julianhyde], it seems to cause test failures in Java 8:
https://travis-ci.org/apache/calcite/jobs/637863311#L1424-L1440
Can you please check that?
Should `ImmutableBeans` require the interface to be public?
> Immutable beans, powered by reflection
> --
>
> Key: CALCITE-3328
> URL: https://issues.apache.org/jira/browse/CALCITE-3328
> Project: Calcite
> Issue Type: Bug
>Reporter: Julian Hyde
>Assignee: Julian Hyde
>Priority: Major
> Fix For: 1.22.0
>
>
> In quite a few places we have immutable config classes, and because they are
> immutable we have builders. It all gets quite verbose.
> I propose to add a utility class, {{ImmutableBeans}}, that is able to
> generate an implementation of a given interface. For example,
> {code:java}
> interface MyBean {
> @Property int getAge();
> MyBean withAge(int age);
> @Property String getName();
> MyBean withName(String name);
> }
> MyBean b = ImmutableBeans.create(MyBean.class);
> assertThat(b.withAge(37).withName("Fred").getAge(), is(37));
> {code}
> We could replace {{SqlParser.ConfigBuilder}}, {{Frameworks.ConfigBuilder}},
> {{RelBuilder.ConfigBuilder}}, quite a few of the associated {{Config}}
> classes, and perhaps quite a few fluent classes that we use in tests.
> Work in progress:
> https://github.com/julianhyde/calcite/tree/3328-immutable-beans
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (CALCITE-3732) Implement bit functions and operators
[ https://issues.apache.org/jira/browse/CALCITE-3732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17016880#comment-17016880 ] hailong wang edited comment on CALCITE-3732 at 1/16/20 12:51 PM: - Thanks [~julianhyde] [~amaliujia]. I conclude as follows: 1. In the default parser, we can support: ||Function Name|| |BIT_COUNT| |BIT_AND| |BIT_OR| |BIT_XOR| These functions are in SqlStdOperatorTable. The input Type can be TINYINT, SMALLINT, INT, BIGINT, BINARY and VARBINARY. The return type is same as input type. For Oracle, we can support: ||Function Name|| |BitAnd| |BitOr| |BitXor| |BitNot| |BitShift| |BitClear| |BitRotate| |BitSet| For Snowflake, we can support: ||Function Name|| |BITSHIFTLEFT| |BITSHIFTRIGHT| For DB2, we can support: ||Function Name|| |BITANDNOT| These functions are in SqlLibraryOperators. The input Type only supports numeric values, and will be converted to an BIGINT before the bitwise function. The result type is BIGINT. 2. In the babel parser: For Mysql, we can support: ||Function Name|| |&| ||\||| |~| |^| |<<| |>>| For PostgreSQL, we can support: ||Function Name|| |#| These functions are in SqlLibraryOperators. The input type can The input Type can be TINYINT, SMALLINT, INT, BIGINT, BINARY and VARBINARY, and numeric values will be cast to BIGINT. The result type depends on whether the bit argument is evaluated as a binary string or number: 1.Binary-string evaluation occurs when the arguments have a binary string type. Numeric evaluation occurs otherwise, with argument conversion to unsigned 64-bit integers as necessary. 2.Binary-string evaluation produces a binary string of the same length as the arguments. If the arguments have unequal lengths, an ER_INVALID_BITWISE_OPERANDS_SIZE error occurs. Numeric evaluation produces an unsigned 64-bit integer. What do you think of these above? BTW, I found Oracle, Snowflake and DB2 only support number for input type, should we need to support binary and varbinary? was (Author: hailong wang): Thanks [~julianhyde] [~amaliujia]. I conclude as follows: 1. In the default parser, we can support: ||Function Name|| |BIT_COUNT| |BIT_AND| |BIT_OR| |BIT_XOR| These functions are in SqlStdOperatorTable. The input Type can be TINYINT, SMALLINT, INT, BIGINT, BINARY and VARBINARY. The return type is same as input type. For Oracle, we can support: ||Function Name|| |BitAnd| |BitOr| |BitXor| |BitNot| |BitShift| |BitClear| |BitRotate| |BitSet| For Snowflake, we can support: ||Function Name|| |BITSHIFTLEFT| |BITSHIFTRIGHT| For DB2, we can support: ||Function Name|| |BITANDNOT| These functions are in SqlLibraryOperators. The input Type only supports numeric values, and will be converted to an BIGINT before the bitwise function. The result type is BIGINT. 2. In the babel parser: For Mysql, we can support: ||Function Name|| |&| |\|| |~| |^| |<<| |>>| For PostgreSQL, we can support: ||Function Name|| |#| These functions are in SqlLibraryOperators. The input type can The input Type can be TINYINT, SMALLINT, INT, BIGINT, BINARY and VARBINARY, and numeric values will be cast to BIGINT. The result type depends on whether the bit argument is evaluated as a binary string or number: 1.Binary-string evaluation occurs when the arguments have a binary string type. Numeric evaluation occurs otherwise, with argument conversion to unsigned 64-bit integers as necessary. 2.Binary-string evaluation produces a binary string of the same length as the arguments. If the arguments have unequal lengths, an ER_INVALID_BITWISE_OPERANDS_SIZE error occurs. Numeric evaluation produces an unsigned 64-bit integer. What do you think of these above? BTW, I found Oracle, Snowflake and DB2 only support number for input type, should we need to support binary and varbinary? > Implement bit functions and operators > - > > Key: CALCITE-3732 > URL: https://issues.apache.org/jira/browse/CALCITE-3732 > Project: Calcite > Issue Type: Improvement > Components: core >Affects Versions: 1.21.0 >Reporter: hailong wang >Assignee: hailong wang >Priority: Major > Fix For: 1.22.0 > > > Bit function is non-standard operators, but all db has implemented, such as > mysql, postgresql. > Calcite has implemented BIT_AND, BIT_OR in > https://issues.apache.org/jira/browse/CALCITE-2770, BIT_XOR in > https://issues.apache.org/jira/browse/CALCITE-3591. BIT_COUNT is in progress > https://issues.apache.org/jira/browse/CALCITE-3697, BIT_NOT(~) is in progress > https://issues.apache.org/jira/browse/CALCITE-3592. > So I think we should also implement Bitwise AND(&), Right shift(>>), Left > shift(<<), Bitwise XOR(^), Bitwise OR(|). And data types support tinyint, > smallint, int, bigint like before. > >
[jira] [Resolved] (CALCITE-3742) Update Gradle: 6.0.1 -> 6.1
[ https://issues.apache.org/jira/browse/CALCITE-3742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Sitnikov resolved CALCITE-3742. Fix Version/s: avatica-1.17.0 1.22.0 Resolution: Fixed Fixed in https://github.com/apache/calcite/commit/0ef28f08bc555c518c9d2fec5b6e2aa5ae6620ee , https://github.com/apache/calcite-avatica/commit/9245f4aff3a3ca0390589dde6c42369a15842f10 Release tested in https://github.com/vlsi/vlsi-release-plugins/runs/393118241 and https://github.com/vlsi/vlsi-release-plugins/runs/393118224 > Update Gradle: 6.0.1 -> 6.1 > --- > > Key: CALCITE-3742 > URL: https://issues.apache.org/jira/browse/CALCITE-3742 > Project: Calcite > Issue Type: Improvement >Affects Versions: avatica-1.16.0, 1.21.0 >Reporter: Vladimir Sitnikov >Assignee: Vladimir Sitnikov >Priority: Major > Fix For: 1.22.0, avatica-1.17.0 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-3732) Implement bit functions and operators
[ https://issues.apache.org/jira/browse/CALCITE-3732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17016880#comment-17016880 ] hailong wang commented on CALCITE-3732: --- Thanks [~julianhyde] [~amaliujia]. I conclude as follows: 1. In the default parser, we can support: ||Function Name|| |BIT_COUNT| |BIT_AND| |BIT_OR| |BIT_XOR| These functions are in SqlStdOperatorTable. The input Type can be TINYINT, SMALLINT, INT, BIGINT, BINARY and VARBINARY. The return type is same as input type. For Oracle, we can support: ||Function Name|| |BitAnd| |BitOr| |BitXor| |BitNot| |BitShift| |BitClear| |BitRotate| |BitSet| For Snowflake, we can support: ||Function Name|| |BITSHIFTLEFT| |BITSHIFTRIGHT| For DB2, we can support: ||Function Name|| |BITANDNOT| These functions are in SqlLibraryOperators. The input Type only supports numeric values, and will be converted to an BIGINT before the bitwise function. The result type is BIGINT. 2. In the babel parser: For Mysql, we can support: ||Function Name|| |&| |\|| |~| |^| |<<| |>>| For PostgreSQL, we can support: ||Function Name|| |#| These functions are in SqlLibraryOperators. The input type can The input Type can be TINYINT, SMALLINT, INT, BIGINT, BINARY and VARBINARY, and numeric values will be cast to BIGINT. The result type depends on whether the bit argument is evaluated as a binary string or number: 1.Binary-string evaluation occurs when the arguments have a binary string type. Numeric evaluation occurs otherwise, with argument conversion to unsigned 64-bit integers as necessary. 2.Binary-string evaluation produces a binary string of the same length as the arguments. If the arguments have unequal lengths, an ER_INVALID_BITWISE_OPERANDS_SIZE error occurs. Numeric evaluation produces an unsigned 64-bit integer. What do you think of these above? BTW, I found Oracle, Snowflake and DB2 only support number for input type, should we need to support binary and varbinary? > Implement bit functions and operators > - > > Key: CALCITE-3732 > URL: https://issues.apache.org/jira/browse/CALCITE-3732 > Project: Calcite > Issue Type: Improvement > Components: core >Affects Versions: 1.21.0 >Reporter: hailong wang >Assignee: hailong wang >Priority: Major > Fix For: 1.22.0 > > > Bit function is non-standard operators, but all db has implemented, such as > mysql, postgresql. > Calcite has implemented BIT_AND, BIT_OR in > https://issues.apache.org/jira/browse/CALCITE-2770, BIT_XOR in > https://issues.apache.org/jira/browse/CALCITE-3591. BIT_COUNT is in progress > https://issues.apache.org/jira/browse/CALCITE-3697, BIT_NOT(~) is in progress > https://issues.apache.org/jira/browse/CALCITE-3592. > So I think we should also implement Bitwise AND(&), Right shift(>>), Left > shift(<<), Bitwise XOR(^), Bitwise OR(|). And data types support tinyint, > smallint, int, bigint like before. > > Refence: > [https://dev.mysql.com/doc/refman/8.0/en/bit-functions.html#operator_bitwise-invert] > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CALCITE-3742) Update Gradle: 6.0.1 -> 6.1
[ https://issues.apache.org/jira/browse/CALCITE-3742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Sitnikov updated CALCITE-3742: --- Affects Version/s: avatica-1.16.0 > Update Gradle: 6.0.1 -> 6.1 > --- > > Key: CALCITE-3742 > URL: https://issues.apache.org/jira/browse/CALCITE-3742 > Project: Calcite > Issue Type: Improvement >Affects Versions: avatica-1.16.0, 1.21.0 >Reporter: Vladimir Sitnikov >Assignee: Vladimir Sitnikov >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CALCITE-3742) Update Gradle: 6.0.1 -> 6.1
Vladimir Sitnikov created CALCITE-3742: -- Summary: Update Gradle: 6.0.1 -> 6.1 Key: CALCITE-3742 URL: https://issues.apache.org/jira/browse/CALCITE-3742 Project: Calcite Issue Type: Improvement Affects Versions: 1.21.0 Reporter: Vladimir Sitnikov Assignee: Vladimir Sitnikov -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (CALCITE-3732) Implement bit functions and operators
[ https://issues.apache.org/jira/browse/CALCITE-3732?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] hailong wang reassigned CALCITE-3732: - Assignee: hailong wang > Implement bit functions and operators > - > > Key: CALCITE-3732 > URL: https://issues.apache.org/jira/browse/CALCITE-3732 > Project: Calcite > Issue Type: Improvement > Components: core >Affects Versions: 1.21.0 >Reporter: hailong wang >Assignee: hailong wang >Priority: Major > Fix For: 1.22.0 > > > Bit function is non-standard operators, but all db has implemented, such as > mysql, postgresql. > Calcite has implemented BIT_AND, BIT_OR in > https://issues.apache.org/jira/browse/CALCITE-2770, BIT_XOR in > https://issues.apache.org/jira/browse/CALCITE-3591. BIT_COUNT is in progress > https://issues.apache.org/jira/browse/CALCITE-3697, BIT_NOT(~) is in progress > https://issues.apache.org/jira/browse/CALCITE-3592. > So I think we should also implement Bitwise AND(&), Right shift(>>), Left > shift(<<), Bitwise XOR(^), Bitwise OR(|). And data types support tinyint, > smallint, int, bigint like before. > > Refence: > [https://dev.mysql.com/doc/refman/8.0/en/bit-functions.html#operator_bitwise-invert] > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-3731) Add IF function for BigQuery, Hive and Spark Dialects
[ https://issues.apache.org/jira/browse/CALCITE-3731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17016823#comment-17016823 ] Jin Xing commented on CALCITE-3731: --- [~vaibhavjain-dm] You can refer to org.apache.calcite.sql.fun.SqlNullifFunction > Add IF function for BigQuery, Hive and Spark Dialects > - > > Key: CALCITE-3731 > URL: https://issues.apache.org/jira/browse/CALCITE-3731 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: vaibhav jain >Priority: Major > Labels: pull-request-available > Time Spent: 3h > Remaining Estimate: 0h > > Adding support for *IF* function for BigQuery, Hive and Spark Dialects. > *Syntax*- IF(condition, true_result, false_result) > If *condition* is true, returns *true_result*, else returns *false_result*. > Document links: > [BigQuery|https://cloud.google.com/bigquery/docs/reference/standard-sql/conditional_expressions] > [Hive > |https://cwiki.apache.org/confluence/display/Hive/LanguageManual+UDF#LanguageManualUDF-ConditionalFunctions] > [Spark Sql|https://spark.apache.org/docs/2.3.1/api/sql/index.html#if] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-3676) VolcanoPlanner. dumpGraphviz should handle exception gracefully
[
https://issues.apache.org/jira/browse/CALCITE-3676?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17016778#comment-17016778
]
Vladimir Sitnikov commented on CALCITE-3676:
[~xndai], Do you have a reproducible example for the issue?
The stacktrace suggests there's an issue either with PartiallyOrderedSet or
with RelTrait#satisfies implementation.
{quote} I have to modify code locally{quote}
You can add -Dcalcite.volcano.dump.graphviz=false property to skip dumping of
the graph.
> VolcanoPlanner. dumpGraphviz should handle exception gracefully
> ---
>
> Key: CALCITE-3676
> URL: https://issues.apache.org/jira/browse/CALCITE-3676
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Haisheng Yuan
>Assignee: Forward Xu
>Priority: Major
> Labels: pull-request-available
> Time Spent: 1h
> Remaining Estimate: 0h
>
> In case VolcanoPlanner can't generate plan due to some RelSubset doesn't have
> best rel, it will dump the sets and Graphviz. Since there is error during
> planning, we want to see the sets in the exception message, but when dumping
> Graphviz, it might encounter another exception (we can't guarantee all the
> sets and subsets are correctly generated for Graphviz), causing failure to
> dump Sets info, which is rather helpful in production system.
> {code:java}
> Caused by: java.lang.AssertionError
> at
> org.apache.calcite.util.PartiallyOrderedSet.findParentsChildren(PartiallyOrderedSet.java:318)
> at
> org.apache.calcite.util.PartiallyOrderedSet.findParents(PartiallyOrderedSet.java:308)
> at
> org.apache.calcite.util.PartiallyOrderedSet.add(PartiallyOrderedSet.java:226)
> at
> org.apache.calcite.plan.volcano.VolcanoPlanner.dumpGraphviz(VolcanoPlanner.java:1320)
> at
> org.apache.calcite.plan.volcano.VolcanoPlanner.dump(VolcanoPlanner.java:1194)
> at
> org.apache.calcite.plan.volcano.RelSubset$CheapestPlanReplacer.visit(RelSubset.java:606)
> at
> org.apache.calcite.plan.volcano.RelSubset.buildCheapestPlan(RelSubset.java:307)
> at
> org.apache.calcite.plan.volcano.VolcanoPlanner.findBestExp(VolcanoPlanner.java:649)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-1861) Spatial Indexes
[ https://issues.apache.org/jira/browse/CALCITE-1861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17016774#comment-17016774 ] Julian Hyde commented on CALCITE-1861: -- [~txy2539], I have now rebased my [1861-spatial|https://github.com/julianhyde/calcite/commits/1861-spatial] branch. There are a few test failures, but the build basically works. Review the last 16 or so commits on that branch, and see which files I have been changing. I apologize that the branch is a mixture of things - in addition to spatial, I'm trying to make table-valued functions work more reliably, and a few commits that fix up after rebasing. In particular, look at changes I made to spatial.iq and RelOptRulesTest.xml. These are both test files, and they give a clue as to what I was doing in the rest of the code. An easy way to start might be to implement one or two geospatial SQL functions. Lots of them are listed in spatial.iq with '# Not implemented' comments. What [~mmior] did in [17cd76af7|https://github.com/apache/calcite/commit/17cd76af7], CALCITE-2031, is a good template to follow. Much more advanced is to use algebraic transforms to implement particular spatial queries efficiently. The testSpatialXxx methods in RelOptRulesTest are examples. > Spatial Indexes > --- > > Key: CALCITE-1861 > URL: https://issues.apache.org/jira/browse/CALCITE-1861 > Project: Calcite > Issue Type: Improvement > Components: spatial >Reporter: Atri Sharma >Priority: Major > > Many Calcite users, like Phoenix and Flink can benefit from support of > Spatial indexes. > See: > http://revenant.ca/www/postgis/workshop/indexing.html -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CALCITE-1861) Spatial Indexes
[ https://issues.apache.org/jira/browse/CALCITE-1861?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Hyde updated CALCITE-1861: - Labels: (was: gsoc2018) > Spatial Indexes > --- > > Key: CALCITE-1861 > URL: https://issues.apache.org/jira/browse/CALCITE-1861 > Project: Calcite > Issue Type: Improvement > Components: spatial >Reporter: Atri Sharma >Priority: Major > > Many Calcite users, like Phoenix and Flink can benefit from support of > Spatial indexes. > See: > http://revenant.ca/www/postgis/workshop/indexing.html -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (CALCITE-3735) In ImmutableBeans, allow interfaces to have default methods
[
https://issues.apache.org/jira/browse/CALCITE-3735?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17016292#comment-17016292
]
Julian Hyde edited comment on CALCITE-3735 at 1/16/20 9:36 AM:
---
Yes, I saw that. In
[2c78bac4|https://github.com/apache/calcite/commit/2c78bac48bfde94c0c77e6e7bb1f95814c8b23c7]
you'll see that I revived {{interface Compatible}} and used different
solutions on JDK 8 than on JDK 9 and later.
was (Author: julianhyde):
Yes, I saw that. In
[aaabee46|https://github.com/julianhyde/calcite/commit/aaabee469d268f9885743dced04255f8113e7fe0]
you'll see that I revived {{interface Compatible}} and used different
solutions on JDK 8 than on JDK 9 and later.
> In ImmutableBeans, allow interfaces to have default methods
> ---
>
> Key: CALCITE-3735
> URL: https://issues.apache.org/jira/browse/CALCITE-3735
> Project: Calcite
> Issue Type: Bug
>Reporter: Julian Hyde
>Assignee: Julian Hyde
>Priority: Major
> Fix For: 1.22.0
>
>
> In ImmutableBeans, allow interfaces to have default methods.
> (These are invoked in the usual way by the client. The mechanics are a bit
> tricky because they involve method handles, and the APIs are different in JDK
> 8 than later JDKs.)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (CALCITE-3735) In ImmutableBeans, allow interfaces to have default methods
[ https://issues.apache.org/jira/browse/CALCITE-3735?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Hyde resolved CALCITE-3735. -- Resolution: Fixed Fixed in [2c78bac4|https://github.com/apache/calcite/commit/2c78bac48bfde94c0c77e6e7bb1f95814c8b23c7]. > In ImmutableBeans, allow interfaces to have default methods > --- > > Key: CALCITE-3735 > URL: https://issues.apache.org/jira/browse/CALCITE-3735 > Project: Calcite > Issue Type: Bug >Reporter: Julian Hyde >Assignee: Julian Hyde >Priority: Major > Fix For: 1.22.0 > > > In ImmutableBeans, allow interfaces to have default methods. > (These are invoked in the usual way by the client. The mechanics are a bit > tricky because they involve method handles, and the APIs are different in JDK > 8 than later JDKs.) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-3741) duplicate ‘ordre by‘ key word generate in select
[ https://issues.apache.org/jira/browse/CALCITE-3741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17016719#comment-17016719 ] Danny Chen commented on CALCITE-3741: - How did you test that ? I use the "select * from products order by score" in SqlParserTest and the SqlOrderBy#unparse works correctly. > duplicate ‘ordre by‘ key word generate in select > > > Key: CALCITE-3741 > URL: https://issues.apache.org/jira/browse/CALCITE-3741 > Project: Calcite > Issue Type: Bug > Components: mongodb-adapter >Affects Versions: 1.17.0 >Reporter: james601232 >Priority: Major > Attachments: image-2020-01-16-14-28-57-662.png > > > Hi > I encoutner a problem use calcite query mongodb. my select sql is "select > * from products order by score". unfortunatly. calcite analysis sql concat > redundant 'order by score' in sql. > debug screenshot as following: > !image-2020-01-16-14-28-57-662.png! > could you help me what wrong happen. > Tks > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-3741) duplicate ‘ordre by‘ key word generate in select
[ https://issues.apache.org/jira/browse/CALCITE-3741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17016699#comment-17016699 ] james601232 commented on CALCITE-3741: -- Dear [~danny0405] my sql is “select * from products order by score”. after calcite analsys found duplicate order by in sql > duplicate ‘ordre by‘ key word generate in select > > > Key: CALCITE-3741 > URL: https://issues.apache.org/jira/browse/CALCITE-3741 > Project: Calcite > Issue Type: Bug > Components: mongodb-adapter >Affects Versions: 1.17.0 >Reporter: james601232 >Priority: Major > Attachments: image-2020-01-16-14-28-57-662.png > > > Hi > I encoutner a problem use calcite query mongodb. my select sql is "select > * from products order by score". unfortunatly. calcite analysis sql concat > redundant 'order by score' in sql. > debug screenshot as following: > !image-2020-01-16-14-28-57-662.png! > could you help me what wrong happen. > Tks > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-3741) duplicate ‘ordre by‘ key word generate in select
[ https://issues.apache.org/jira/browse/CALCITE-3741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17016698#comment-17016698 ] james601232 commented on CALCITE-3741: -- Dear [~danny0405] > duplicate ‘ordre by‘ key word generate in select > > > Key: CALCITE-3741 > URL: https://issues.apache.org/jira/browse/CALCITE-3741 > Project: Calcite > Issue Type: Bug > Components: mongodb-adapter >Affects Versions: 1.17.0 >Reporter: james601232 >Priority: Major > Attachments: image-2020-01-16-14-28-57-662.png > > > Hi > I encoutner a problem use calcite query mongodb. my select sql is "select > * from products order by score". unfortunatly. calcite analysis sql concat > redundant 'order by score' in sql. > debug screenshot as following: > !image-2020-01-16-14-28-57-662.png! > could you help me what wrong happen. > Tks > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Issue Comment Deleted] (CALCITE-3741) duplicate ‘ordre by‘ key word generate in select
[ https://issues.apache.org/jira/browse/CALCITE-3741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] james601232 updated CALCITE-3741: - Comment: was deleted (was: Dear [~danny0405] ) > duplicate ‘ordre by‘ key word generate in select > > > Key: CALCITE-3741 > URL: https://issues.apache.org/jira/browse/CALCITE-3741 > Project: Calcite > Issue Type: Bug > Components: mongodb-adapter >Affects Versions: 1.17.0 >Reporter: james601232 >Priority: Major > Attachments: image-2020-01-16-14-28-57-662.png > > > Hi > I encoutner a problem use calcite query mongodb. my select sql is "select > * from products order by score". unfortunatly. calcite analysis sql concat > redundant 'order by score' in sql. > debug screenshot as following: > !image-2020-01-16-14-28-57-662.png! > could you help me what wrong happen. > Tks > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-3741) duplicate ‘ordre by‘ key word generate in select
[ https://issues.apache.org/jira/browse/CALCITE-3741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17016659#comment-17016659 ] Danny Chen commented on CALCITE-3741: - Why you write multiple "order by"s in your query, i tried MySQL 5.6 and PostgreSQL 11g, they all fails with such syntax. > duplicate ‘ordre by‘ key word generate in select > > > Key: CALCITE-3741 > URL: https://issues.apache.org/jira/browse/CALCITE-3741 > Project: Calcite > Issue Type: Bug > Components: mongodb-adapter >Affects Versions: 1.17.0 >Reporter: james601232 >Priority: Major > Attachments: image-2020-01-16-14-28-57-662.png > > > Hi > I encoutner a problem use calcite query mongodb. my select sql is "select > * from products order by score". unfortunatly. calcite analysis sql concat > redundant 'order by score' in sql. > debug screenshot as following: > !image-2020-01-16-14-28-57-662.png! > could you help me what wrong happen. > Tks > -- This message was sent by Atlassian Jira (v8.3.4#803005)
