[jira] [Resolved] (CALCITE-2213) Geode integration tests are failing

[Jesus Camacho Rodriguez (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CALCITE-2213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jesus Camacho Rodriguez resolved CALCITE-2213.
--
Resolution: Fixed

Fixed in http://git-wip-us.apache.org/repos/asf/calcite/commit/8746ef792 .

> Geode integration tests are failing
> ---
>
> Key: CALCITE-2213
> URL: https://issues.apache.org/jira/browse/CALCITE-2213
> Project: Calcite
>  Issue Type: Bug
>  Components: geode
>Reporter: Jesus Camacho Rodriguez
>Assignee: Jesus Camacho Rodriguez
>Priority: Major
> Fix For: 1.16.0
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (CALCITE-2213) Geode integration tests are failing

[Jesus Camacho Rodriguez (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CALCITE-2213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jesus Camacho Rodriguez updated CALCITE-2213:
-
Summary: Geode integration tests are failing  (was: Geode integration tests 
are failing with mismatch in expected plan)

> Geode integration tests are failing
> ---
>
> Key: CALCITE-2213
> URL: https://issues.apache.org/jira/browse/CALCITE-2213
> Project: Calcite
>  Issue Type: Bug
>  Components: geode
>Reporter: Jesus Camacho Rodriguez
>Assignee: Jesus Camacho Rodriguez
>Priority: Major
> Fix For: 1.16.0
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (CALCITE-2213) Geode integration tests are failing with mismatch in expected plan

[Jesus Camacho Rodriguez (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CALCITE-2213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jesus Camacho Rodriguez updated CALCITE-2213:
-
Summary: Geode integration tests are failing with mismatch in expected plan 
 (was: Geode integration tests are failing with expected plan mismatch)

> Geode integration tests are failing with mismatch in expected plan
> --
>
> Key: CALCITE-2213
> URL: https://issues.apache.org/jira/browse/CALCITE-2213
> Project: Calcite
>  Issue Type: Bug
>  Components: geode
>Reporter: Jesus Camacho Rodriguez
>Assignee: Jesus Camacho Rodriguez
>Priority: Major
> Fix For: 1.16.0
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (CALCITE-2213) Geode integration tests are failing with expected plan mismatch

[Jesus Camacho Rodriguez (JIRA)]

Jesus Camacho Rodriguez created CALCITE-2213:


 Summary: Geode integration tests are failing with expected plan 
mismatch
 Key: CALCITE-2213
 URL: https://issues.apache.org/jira/browse/CALCITE-2213
 Project: Calcite
  Issue Type: Bug
  Components: geode
Reporter: Jesus Camacho Rodriguez
Assignee: Jesus Camacho Rodriguez
 Fix For: 1.16.0






--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CALCITE-2212) Avatica - Enforce Java version via maven-enforcer-plugin

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CALCITE-2212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16397973#comment-16397973
 ] 

ASF GitHub Bot commented on CALCITE-2212:
-

Github user risdenk commented on the issue:

https://github.com/apache/calcite-avatica/pull/31
  
@joshelser - FYI same as last PR just updated commit name and PR title.


> Avatica - Enforce Java version via maven-enforcer-plugin
> 
>
> Key: CALCITE-2212
> URL: https://issues.apache.org/jira/browse/CALCITE-2212
> Project: Calcite
>  Issue Type: Task
>  Components: avatica
>Reporter: Josh Elser
>Assignee: Kevin Risden
>Priority: Critical
> Fix For: avatica-1.12.0
>
>
> Now that jdk7 support has been dropped, we should add some logic to the build 
> to fail obviously when a version of Java is used that we don't support.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CALCITE-2212) Avatica - Enforce Java version via maven-enforcer-plugin

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CALCITE-2212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16397972#comment-16397972
 ] 

ASF GitHub Bot commented on CALCITE-2212:
-

Github user risdenk commented on the issue:

https://github.com/apache/calcite-avatica/pull/31
  
Updated from PR #30 since CALCITE-2212 is the new JIRA specifically for 
Avatica


> Avatica - Enforce Java version via maven-enforcer-plugin
> 
>
> Key: CALCITE-2212
> URL: https://issues.apache.org/jira/browse/CALCITE-2212
> Project: Calcite
>  Issue Type: Task
>  Components: avatica
>Reporter: Josh Elser
>Assignee: Kevin Risden
>Priority: Critical
> Fix For: avatica-1.12.0
>
>
> Now that jdk7 support has been dropped, we should add some logic to the build 
> to fail obviously when a version of Java is used that we don't support.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CALCITE-2212) Avatica - Enforce Java version via maven-enforcer-plugin

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CALCITE-2212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16397971#comment-16397971
 ] 

ASF GitHub Bot commented on CALCITE-2212:
-

GitHub user risdenk opened a pull request:

https://github.com/apache/calcite-avatica/pull/31

[CALCITE-2212] Enforce minimum JDK 8 via maven-enforcer-plugin

**Tested with JDK 7**
```
mvn --version
Apache Maven 3.5.3 (3383c37e1f9e9b3bc3df5050c29c8aff9f295297; 
2018-02-24T13:49:05-06:00)
Maven home: /usr/local/Cellar/maven/3.5.3/libexec
Java version: 1.7.0_80, vendor: Oracle Corporation
Java home: 
/Library/Java/JavaVirtualMachines/jdk1.7.0_80.jdk/Contents/Home/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "mac os x", version: "10.13.3", arch: "x86_64", family: "mac"

mvn clean install -DskipTests
...
[INFO] --- maven-enforcer-plugin:3.0.0-M1:enforce (enforce-java) @ calcite 
---
[WARNING] Rule 0: org.apache.maven.plugins.enforcer.RequireJavaVersion 
failed with message:
Detected JDK Version: 1.7.0-80 is not in the allowed range [1.8,).
...
[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-enforcer-plugin:3.0.0-M1:enforce (enforce-java) 
on project avatica-parent: Some Enforcer rules have failed. Look above for 
specific messages explaining why the rule failed. -> [Help 1]
...
```

Checked with JDK 8, 9, and 10-ea and build works as designed.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/risdenk/calcite-avatica CALCITE-2212

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/calcite-avatica/pull/31.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #31


commit e474167f3bd0b0a8be01e0c73a8cfb69ea6db731
Author: Kevin Risden 
Date:   2018-03-13T00:12:17Z

[CALCITE-2212] Enforce minimum JDK 8 via maven-enforcer-plugin




> Avatica - Enforce Java version via maven-enforcer-plugin
> 
>
> Key: CALCITE-2212
> URL: https://issues.apache.org/jira/browse/CALCITE-2212
> Project: Calcite
>  Issue Type: Task
>  Components: avatica
>Reporter: Josh Elser
>Assignee: Kevin Risden
>Priority: Critical
> Fix For: avatica-1.12.0
>
>
> Now that jdk7 support has been dropped, we should add some logic to the build 
> to fail obviously when a version of Java is used that we don't support.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CALCITE-2207) Enforce Java version via maven-enforcer-plugin

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CALCITE-2207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16397966#comment-16397966
 ] 

ASF GitHub Bot commented on CALCITE-2207:
-

Github user risdenk closed the pull request at:

https://github.com/apache/calcite-avatica/pull/30


> Enforce Java version via maven-enforcer-plugin
> --
>
> Key: CALCITE-2207
> URL: https://issues.apache.org/jira/browse/CALCITE-2207
> Project: Calcite
>  Issue Type: Task
>  Components: core
>Reporter: Josh Elser
>Assignee: Kevin Risden
>Priority: Critical
> Fix For: 1.16.0
>
>
> Now that jdk7 support has been dropped, we should add some logic to the build 
> to fail obviously when a version of Java is used that we don't support.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CALCITE-2207) Enforce Java version via maven-enforcer-plugin

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CALCITE-2207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16397965#comment-16397965
 ] 

ASF GitHub Bot commented on CALCITE-2207:
-

Github user risdenk commented on the issue:

https://github.com/apache/calcite-avatica/pull/30
  
@joshelser - Going to close this and resubmit for CALCITE-2212 which is 
specifically for avatica instead of Calcite proper.


> Enforce Java version via maven-enforcer-plugin
> --
>
> Key: CALCITE-2207
> URL: https://issues.apache.org/jira/browse/CALCITE-2207
> Project: Calcite
>  Issue Type: Task
>  Components: core
>Reporter: Josh Elser
>Assignee: Kevin Risden
>Priority: Critical
> Fix For: 1.16.0
>
>
> Now that jdk7 support has been dropped, we should add some logic to the build 
> to fail obviously when a version of Java is used that we don't support.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CALCITE-2207) Enforce Java version via maven-enforcer-plugin

[Kevin Risden (JIRA)]

[ 
https://issues.apache.org/jira/browse/CALCITE-2207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16397964#comment-16397964
 ] 

Kevin Risden commented on CALCITE-2207:
---

[~jcamachorodriguez] - Thanks! I probably should have created a separate Jira 
originally anyway :/ 

> Enforce Java version via maven-enforcer-plugin
> --
>
> Key: CALCITE-2207
> URL: https://issues.apache.org/jira/browse/CALCITE-2207
> Project: Calcite
>  Issue Type: Task
>  Components: core
>Reporter: Josh Elser
>Assignee: Kevin Risden
>Priority: Critical
> Fix For: 1.16.0
>
>
> Now that jdk7 support has been dropped, we should add some logic to the build 
> to fail obviously when a version of Java is used that we don't support.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CALCITE-1861) Spatial Indexes

[Julian Hyde (JIRA)]

[ 
https://issues.apache.org/jira/browse/CALCITE-1861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16397959#comment-16397959
 ] 

Julian Hyde commented on CALCITE-1861:
--

Related work in Druid: https://github.com/druid-io/druid/issues/5482

> Spatial Indexes
> ---
>
> Key: CALCITE-1861
> URL: https://issues.apache.org/jira/browse/CALCITE-1861
> Project: Calcite
>  Issue Type: Improvement
>  Components: spatial
>Reporter: Atri Sharma
>Assignee: Julian Hyde
>Priority: Major
>  Labels: gsoc2018
>
> 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
(v7.6.3#76005)

[jira] [Comment Edited] (CALCITE-2211) Type of BigInteger should be BIGINT

[Shuyi Chen (JIRA)]

[ 
https://issues.apache.org/jira/browse/CALCITE-2211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16397750#comment-16397750
 ] 

Shuyi Chen edited comment on CALCITE-2211 at 3/14/18 1:40 AM:
--

Good point. java.math.BigInteger has unlimited precision, I dont think there is 
a sql type equivalent to it. The close I think is decimal. 

In JavaToSqlTypeConversionRules, we are mapping BigDecimal(unlimited precision) 
to Sql.Decimal already, so I think we can convert BigInteger to Sql.Decimal as 
well. Transact-SQL do conversion of integer to Decimal if it's outside the 
integer range. 
([https://docs.microsoft.com/en-us/sql/t-sql/data-types/int-bigint-smallint-and-tinyint-transact-sql#converting-integer-data].
 What do you think?


was (Author: suez1224):
Good point. java.math.BigInteger has unlimited precision, I dont think there is 
a sql type equivalent to it. The close I think is decimal. 

In JavaToSqlTypeConversionRules, we are mapping BigDecimal(unlimited precision) 
to Sql.Decimal already, so I think we can convert BigInteger to Sql.Decimal as 
well. Transact-SQL do conversion of integer to Decimal if it's outside the 
integer range. 
([https://docs.microsoft.com/en-us/sql/t-sql/data-types/int-bigint-smallint-and-tinyint-transact-sql#converting-integer-data]

> Type of BigInteger should be BIGINT
> ---
>
> Key: CALCITE-2211
> URL: https://issues.apache.org/jira/browse/CALCITE-2211
> Project: Calcite
>  Issue Type: Bug
>Affects Versions: 1.15.0
>Reporter: Eyal Segal
>Assignee: Julian Hyde
>Priority: Major
>
> Vertica DB returns BigInteger values as BigInteger. It seems that 
> JavaToSqlTypeConversionRules doesn't support mapping between BigInteger to 
> BIGINT.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (CALCITE-2211) Type of BigInteger should be BIGINT

[Shuyi Chen (JIRA)]

[ 
https://issues.apache.org/jira/browse/CALCITE-2211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16397750#comment-16397750
 ] 

Shuyi Chen edited comment on CALCITE-2211 at 3/14/18 1:39 AM:
--

Good point. java.math.BigInteger has unlimited precision, I dont think there is 
a sql type equivalent to it. The close I think is decimal. 

In JavaToSqlTypeConversionRules, we are mapping BigDecimal(unlimited precision) 
to Sql.Decimal already, so I think we can convert BigInteger to Sql.Decimal as 
well. Transact-SQL do conversion of integer to Decimal if it's outside the 
integer range. 
([https://docs.microsoft.com/en-us/sql/t-sql/data-types/int-bigint-smallint-and-tinyint-transact-sql#converting-integer-data]


was (Author: suez1224):
Good point. java.math.BigInteger has unlimited decision, I dont think there is 
a sql type equivalent to it. The close I think is decimal. 

In JavaToSqlTypeConversionRules, we are mapping BigDecimal(unlimited precision) 
to Sql.Decimal already, so I think we can convert BigInteger to Sql.Decimal as 
well. Transact-SQL do conversion of integer to Decimal if it's outside the 
integer range. 
(https://docs.microsoft.com/en-us/sql/t-sql/data-types/int-bigint-smallint-and-tinyint-transact-sql#converting-integer-data

> Type of BigInteger should be BIGINT
> ---
>
> Key: CALCITE-2211
> URL: https://issues.apache.org/jira/browse/CALCITE-2211
> Project: Calcite
>  Issue Type: Bug
>Affects Versions: 1.15.0
>Reporter: Eyal Segal
>Assignee: Julian Hyde
>Priority: Major
>
> Vertica DB returns BigInteger values as BigInteger. It seems that 
> JavaToSqlTypeConversionRules doesn't support mapping between BigInteger to 
> BIGINT.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (CALCITE-2188) JDBC adapter generates invalid SQL for DATE/INTERVAL arithmetic

[Jesus Camacho Rodriguez (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CALCITE-2188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jesus Camacho Rodriguez updated CALCITE-2188:
-
Fix Version/s: (was: 1.16.0)
   1.17.0

> JDBC adapter generates invalid SQL for DATE/INTERVAL arithmetic
> ---
>
> Key: CALCITE-2188
> URL: https://issues.apache.org/jira/browse/CALCITE-2188
> Project: Calcite
>  Issue Type: Bug
>  Components: jdbc-adapter
>Reporter: Rahul Raj
>Assignee: Julian Hyde
>Priority: Major
> Fix For: 1.17.0
>
>
> Calcite gives errors on Date interval addition/subtraction in the WHERE 
> clause. For example the query {code}select  * from \"sakila\".\"actor\" where 
>  \"last_update\" - INTERVAL '20' SECOND > TIMESTAMP '2005-10-17 
> 00:00:00'{code} gives
> {noformat}
> Caused by: java.lang.UnsupportedOperationException: class 
> org.apache.calcite.sql.SqlSyntax$6: SPECIAL
>      at org.apache.calcite.util.Util.needToImplement(Util.java:925) 
> ~[calcite-core-1.15.0-drill-r0.jar:1.15.0-drill-r0]
>      at org.apache.calcite.sql.SqlSyntax$6.unparse(SqlSyntax.java:116) 
> ~[calcite-core-1.15.0-drill-r0.jar:1.15.0-drill-r0]
>      at org.apache.calcite.sql.SqlOperator.unparse(SqlOperator.java:332) 
> ~[calcite-core-1.15.0-drill-r0.jar:1.15.0-drill-r0]
>      at org.apache.calcite.sql.SqlDialect.unparseCall(SqlDialect.java:332) 
> ~[calcite-core-1.15.0-drill-r0.jar:1.15.0-drill-r0]
>      at 
> org.apache.calcite.sql.dialect.MysqlSqlDialect.unparseCall(MysqlSqlDialect.java:154)
>  ~[calcite-core-1.15.0-drill-r0.jar:1.15.0-drill-r0]
>      at org.apache.calcite.sql.SqlCall.unparse(SqlCall.java:103) 
> ~[calcite-core-1.15.0-drill-r0.jar:1.15.0-drill-r0]
>      at org.apache.calcite.sql.SqlUtil.unparseBinarySyntax(SqlUtil.java:323) 
> ~[calcite-core-1.15.0-drill-r0.jar:1.15.0-drill-r0]
>      at org.apache.calcite.sql.SqlSyntax$3.unparse(SqlSyntax.java:65) 
> ~[calcite-core-1.15.0-drill-r0.jar:1.15.0-drill-r0]
>      at org.apache.calcite.sql.SqlOperator.unparse(SqlOperator.java:332) 
> ~[calcite-core-1.15.0-drill-r0.jar:1.15.0-drill-r0]
>      at org.apache.calcite.sql.SqlDialect.unparseCall(SqlDialect.java:332) 
> ~[calcite-core-1.15.0-drill-r0.jar:1.15.0-drill-r0]
>      at 
> org.apache.calcite.sql.dialect.MysqlSqlDialect.unparseCall(MysqlSqlDialect.java:154)
>  ~[calcite-core-1.15.0-drill-r0.jar:1.15.0-drill-r0]
>      at org.apache.calcite.sql.SqlCall.unparse(SqlCall.java:103) 
> ~[calcite-core-1.15.0-drill-r0.jar:1.15.0-drill-r0]
>      at org.apache.calcite.sql.SqlNodeList.andOrList(SqlNodeList.java:142) 
> ~[calcite-core-1.15.0-drill-r0.jar:1.15.0-drill-r0]
>      at 
> org.apache.calcite.sql.SqlOperator.unparseListClause(SqlOperator.java:347) 
> ~[calcite-core-1.15.0-drill-r0.jar:1.15.0-drill-r0]
>      at 
> org.apache.calcite.sql.SqlSelectOperator.unparse(SqlSelectOperator.java:197) 
> ~[calcite-core-1.15.0-drill-r0.jar:1.15.0-drill-r0]
>      at org.apache.calcite.sql.SqlSelect.unparse(SqlSelect.java:240) 
> ~[calcite-core-1.15.0-drill-r0.jar:1.15.0-drill-r0]
>      at org.apache.calcite.sql.SqlNode.toSqlString(SqlNode.java:152) 
> ~[calcite-core-1.15.0-drill-r0.jar:1.15.0-drill-r0]
>      at org.apache.calcite.sql.SqlNode.toSqlString(SqlNode.java:158) 
> ~[calcite-core-1.15.0-drill-r0.jar:1.15.0-drill-r0]
>      at org.apache.drill.exec.store.jdbc.JdbcPrel.(JdbcPrel.java:65) 
> ~[drill-jdbc-storage-1.13.0-SNAPSHOT.jar:1.13.0-SNAPSHOT]{noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (CALCITE-2205) One more Infinite loop for JoinPushTransitivePredicatesRule

[Jesus Camacho Rodriguez (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CALCITE-2205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jesus Camacho Rodriguez updated CALCITE-2205:
-
Fix Version/s: (was: 1.16.0)
   1.17.0

> One more Infinite loop for JoinPushTransitivePredicatesRule
> ---
>
> Key: CALCITE-2205
> URL: https://issues.apache.org/jira/browse/CALCITE-2205
> Project: Calcite
>  Issue Type: Bug
>  Components: core
>Affects Versions: 1.15.0
>Reporter: Vitalii Diravka
>Assignee: Julian Hyde
>Priority: Major
> Fix For: 1.17.0
>
>
> CALCITE-2200 resolves some cases of infinite loop via stopping of recursion 
> in HepPlanner#applyRules, when newVertex is the same as vertex.
> In this jira one more case of infinite loop is described:
> JoinPushTransitivePredicatesRule#onMatch generates new right or left inputs 
> via using RelBuilder#filter method on top of LogicalFilter RelNode with the 
> same condition. 
> In this case a new RelNode shouldn't be created. Possible fix to change logic 
> of RelBuilder#filter method.
> TestCase for reproduce:
> {code}
>   @Test public void testJoinPushTransitivePredicatesRule2() {
> HepProgramBuilder builder = new HepProgramBuilder();
> builder.addRuleInstance(JoinPushTransitivePredicatesRule.INSTANCE);
> HepProgram build = builder.build();
> HepPlanner hepPlanner = new HepPlanner(build);
> final String sql = "select n1.SAL from EMPNULLABLES_20 n1 where n1.SAL\n"
> + "IN (select n2.SAL from EMPNULLABLES_20 n2 "
> + "where n1.SAL = n2.SAL or n1.SAL = 4)";
> sql(sql)
> .withDecorrelation(true)
> .with(hepPlanner)
> .check();
>   }
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CALCITE-2098) Push filters to Druid Query Scan when we have OR of AND clauses

[Jesus Camacho Rodriguez (JIRA)]

[ 
https://issues.apache.org/jira/browse/CALCITE-2098?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16397853#comment-16397853
 ] 

Jesus Camacho Rodriguez commented on CALCITE-2098:
--

Fixed as part of CALCITE-2097.

> Push filters to Druid Query Scan when we have OR of AND clauses
> ---
>
> Key: CALCITE-2098
> URL: https://issues.apache.org/jira/browse/CALCITE-2098
> Project: Calcite
>  Issue Type: Bug
>  Components: druid
>Reporter: slim bouguerra
>Assignee: slim bouguerra
>Priority: Major
> Fix For: 1.16.0
>
>
> Currently Druid Filter Rule doesn't push filters like {code} OR(AND(F1,F2), 
> F3){code} 
> This is due to optimization logic 
> {code}org.apache.calcite.adapter.druid.DruidRules.DruidFilterRule.splitFilters{code}
> Here is an test example:
> {code}
> /**
>* @TODO Fix this case, Druid can handel this kind of expression but the way
>* org.apache.calcite.adapter.druid.DruidRules.DruidFilterRule.splitFilters
>* works doesn't accept this filter
>   */
>   @Ignore
>   @Test public void testFilterClauseWithMetric2() {
> String sql = "select sum(\"store_sales\")"
> + "from \"foodmart\" where \"product_id\" > 1555 or \"store_cost\" > 
> 5 or extract(year "
> + "from \"timestamp\") = 1997 "
> + "group by floor(\"timestamp\" to DAY),\"product_id\"";
> sql(sql)
> .queryContains(druidChecker("\"queryType\":\"groupBy\"", 
> "{\"type\":\"bound\","
> + 
> "\"dimension\":\"store_cost\",\"lower\":\"5\",\"lowerStrict\":true,"
> + "\"ordering\":\"numeric\"}"))
> .returnsUnordered("to be computed");
>   }
> {code}
> FYI in this example {code} extract(year from \"timestamp\") = 1997{code} will 
> be transformed to {code}(year >= 1996) AND(year <= 1997){code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (CALCITE-2098) Push filters to Druid Query Scan when we have OR of AND clauses

[Jesus Camacho Rodriguez (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CALCITE-2098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jesus Camacho Rodriguez resolved CALCITE-2098.
--
Resolution: Fixed

> Push filters to Druid Query Scan when we have OR of AND clauses
> ---
>
> Key: CALCITE-2098
> URL: https://issues.apache.org/jira/browse/CALCITE-2098
> Project: Calcite
>  Issue Type: Bug
>  Components: druid
>Reporter: slim bouguerra
>Assignee: slim bouguerra
>Priority: Major
> Fix For: 1.16.0
>
>
> Currently Druid Filter Rule doesn't push filters like {code} OR(AND(F1,F2), 
> F3){code} 
> This is due to optimization logic 
> {code}org.apache.calcite.adapter.druid.DruidRules.DruidFilterRule.splitFilters{code}
> Here is an test example:
> {code}
> /**
>* @TODO Fix this case, Druid can handel this kind of expression but the way
>* org.apache.calcite.adapter.druid.DruidRules.DruidFilterRule.splitFilters
>* works doesn't accept this filter
>   */
>   @Ignore
>   @Test public void testFilterClauseWithMetric2() {
> String sql = "select sum(\"store_sales\")"
> + "from \"foodmart\" where \"product_id\" > 1555 or \"store_cost\" > 
> 5 or extract(year "
> + "from \"timestamp\") = 1997 "
> + "group by floor(\"timestamp\" to DAY),\"product_id\"";
> sql(sql)
> .queryContains(druidChecker("\"queryType\":\"groupBy\"", 
> "{\"type\":\"bound\","
> + 
> "\"dimension\":\"store_cost\",\"lower\":\"5\",\"lowerStrict\":true,"
> + "\"ordering\":\"numeric\"}"))
> .returnsUnordered("to be computed");
>   }
> {code}
> FYI in this example {code} extract(year from \"timestamp\") = 1997{code} will 
> be transformed to {code}(year >= 1996) AND(year <= 1997){code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (CALCITE-2018) Queries failed with AssertionError: rel has lower cost than best cost of subset

[Jesus Camacho Rodriguez (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CALCITE-2018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jesus Camacho Rodriguez updated CALCITE-2018:
-
Fix Version/s: (was: 1.16.0)
   1.17.0

> Queries failed with AssertionError: rel has lower cost than best cost of 
> subset
> ---
>
> Key: CALCITE-2018
> URL: https://issues.apache.org/jira/browse/CALCITE-2018
> Project: Calcite
>  Issue Type: Bug
>  Components: core
>Affects Versions: 1.13.0
>Reporter: Volodymyr Vysotskyi
>Assignee: Julian Hyde
>Priority: Critical
> Fix For: 1.17.0
>
>
> *Problem description*
> When rootLogger level is DEBUG, unit tests 
> * MaterializationTest.testMaterializationSubstitution2
> * MaterializationTest.testJoinMaterializationUKFK8
> * MaterializationTest.testJoinMaterializationUKFK6
> * JdbcTest.testWhereNot
> unit tests are failed with error AssertionError: rel has lower cost than best 
> cost of subset.
> Full stack trace for test 
> {{MaterializationTest.testMaterializationSubstitution2}}:
> {noformat}
> java.lang.AssertionError: rel 
> [rel#245:EnumerableUnion.ENUMERABLE.[](input#0=rel#246:Subset#5.ENUMERABLE.[],input#1=rel#239:Subset#6.ENUMERABLE.[0],all=true)]
>  has lower cost {14.0 rows, 19.0 cpu, 0.0 io} than best cost {15.0 rows, 20.0 
> cpu, 0.0 io} of subset [rel#243:Subset#7.ENUMERABLE.[]]
>   at 
> org.apache.calcite.plan.volcano.VolcanoPlanner.validate(VolcanoPlanner.java:906)
>   at 
> org.apache.calcite.plan.volcano.VolcanoPlanner.register(VolcanoPlanner.java:866)
>   at 
> org.apache.calcite.plan.volcano.VolcanoPlanner.ensureRegistered(VolcanoPlanner.java:883)
>   at 
> org.apache.calcite.plan.volcano.VolcanoPlanner.ensureRegistered(VolcanoPlanner.java:101)
>   at 
> org.apache.calcite.rel.AbstractRelNode.onRegister(AbstractRelNode.java:336)
>   at 
> org.apache.calcite.plan.volcano.VolcanoPlanner.registerImpl(VolcanoPlanner.java:1495)
>   at 
> org.apache.calcite.plan.volcano.VolcanoPlanner.register(VolcanoPlanner.java:863)
>   at 
> org.apache.calcite.plan.volcano.VolcanoPlanner.ensureRegistered(VolcanoPlanner.java:883)
>   at 
> org.apache.calcite.plan.volcano.VolcanoPlanner.ensureRegistered(VolcanoPlanner.java:1766)
>   at 
> org.apache.calcite.plan.volcano.VolcanoRuleCall.transformTo(VolcanoRuleCall.java:135)
>   at 
> org.apache.calcite.plan.RelOptRuleCall.transformTo(RelOptRuleCall.java:234)
>   at 
> org.apache.calcite.rel.rules.FilterProjectTransposeRule.onMatch(FilterProjectTransposeRule.java:143)
>   at 
> org.apache.calcite.plan.volcano.VolcanoRuleCall.onMatch(VolcanoRuleCall.java:212)
>   at 
> org.apache.calcite.plan.volcano.VolcanoPlanner.findBestExp(VolcanoPlanner.java:650)
>   at org.apache.calcite.tools.Programs$5.run(Programs.java:326)
>   at 
> org.apache.calcite.tools.Programs$SequenceProgram.run(Programs.java:387)
>   at org.apache.calcite.prepare.Prepare.optimize(Prepare.java:187)
>   at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:318)
>   at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:229)
>   at 
> org.apache.calcite.prepare.CalcitePrepareImpl.prepare2_(CalcitePrepareImpl.java:786)
>   at 
> org.apache.calcite.prepare.CalcitePrepareImpl.prepare_(CalcitePrepareImpl.java:640)
>   at 
> org.apache.calcite.prepare.CalcitePrepareImpl.prepareSql(CalcitePrepareImpl.java:610)
>   at org.apache.calcite.schema.Schemas.prepare(Schemas.java:346)
>   at 
> org.apache.calcite.materialize.MaterializationService$DefaultTableFactory.createTable(MaterializationService.java:374)
>   at 
> org.apache.calcite.materialize.MaterializationService.defineMaterialization(MaterializationService.java:137)
>   at 
> org.apache.calcite.materialize.MaterializationService.defineMaterialization(MaterializationService.java:99)
>   at 
> org.apache.calcite.schema.impl.MaterializedViewTable$MaterializedViewTableMacro.(MaterializedViewTable.java:110)
>   at 
> org.apache.calcite.schema.impl.MaterializedViewTable$MaterializedViewTableMacro.(MaterializedViewTable.java:100)
>   at 
> org.apache.calcite.schema.impl.MaterializedViewTable.create(MaterializedViewTable.java:81)
>   at org.apache.calcite.model.ModelHandler.visit(ModelHandler.java:364)
>   at 
> org.apache.calcite.model.JsonMaterialization.accept(JsonMaterialization.java:42)
>   at org.apache.calcite.model.JsonSchema.visitChildren(JsonSchema.java:98)
>   at 
> org.apache.calcite.model.JsonMapSchema.visitChildren(JsonMapSchema.java:48)
>   at 
> org.apache.calcite.model.ModelHandler.populateSchema(ModelHandler.java:257)
>   at org.apache.calcite.model.ModelHandler.visit(ModelHandler.java:273)
>   at 
> 

[jira] [Updated] (CALCITE-1958) Cannot create Schema objects when using Avatica with HSQLDB

[Jesus Camacho Rodriguez (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CALCITE-1958?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jesus Camacho Rodriguez updated CALCITE-1958:
-
Fix Version/s: (was: 1.16.0)

> Cannot create Schema objects when using Avatica with HSQLDB
> ---
>
> Key: CALCITE-1958
> URL: https://issues.apache.org/jira/browse/CALCITE-1958
> Project: Calcite
>  Issue Type: Bug
>  Components: avatica
>Reporter: Francis Chuang
>Priority: Major
>
> Encountered this one while porting a test from Phoenix to Avatica with HSQLDB 
> for the Go client.
> This happens whether I open the connection with or without a default schema 
> to Avatica.
> I then create a schema: `CREATE SCHEMA IF NOT EXISTS avaticatest`.
> I then attempt to create a table:
> {code}
> CREATE TABLE avaticatest.some_table (
>   int INTEGER PRIMARY KEY
> )
> {code}
> Avatica fails with this message: 
> {code}
> An error was encountered while processing your request: RuntimeException: 
> java.sql.SQLException: invalid schema name: avaticatest in statement [CREATE 
> TABLE avaticatest.some_table (
> int INTEGER PRIMARY KEY
> )] -> SQLException: invalid 
> schema name: avaticatest in statement [CREATE TABLE avaticatest.some_table (
> int INTEGER PRIMARY KEY
> )] -> HsqlException: invalid 
> schema name: avaticatest
> {code}
> I have tried a few things that did not work:
> - Making the schema name uppercase `AVATICATEST` everywhere
> - Making the table name also uppercase everywhere: `SOME_TABLE`.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (CALCITE-1711) Expose elasticsearch as jdbc type rather than custom

[Jesus Camacho Rodriguez (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CALCITE-1711?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jesus Camacho Rodriguez updated CALCITE-1711:
-
Fix Version/s: (was: 1.16.0)

> Expose elasticsearch as jdbc type rather than custom
> 
>
> Key: CALCITE-1711
> URL: https://issues.apache.org/jira/browse/CALCITE-1711
> Project: Calcite
>  Issue Type: Bug
>  Components: avatica
>Reporter: Rani Yaroshinsky
>Priority: Major
>
> I cannot figure out how to add specific schema to elasticsearch adapter, or 
> how to expose is as the relevant fields with types rather than this weird 
> _MAP, which does not expose correctly for any tool.
> An example or documentation, would help with this issue.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (CALCITE-1711) Expose elasticsearch as jdbc type rather than custom

[Jesus Camacho Rodriguez (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CALCITE-1711?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jesus Camacho Rodriguez updated CALCITE-1711:
-
Fix Version/s: 1.16.0

> Expose elasticsearch as jdbc type rather than custom
> 
>
> Key: CALCITE-1711
> URL: https://issues.apache.org/jira/browse/CALCITE-1711
> Project: Calcite
>  Issue Type: Bug
>  Components: avatica
>Reporter: Rani Yaroshinsky
>Priority: Major
> Fix For: 1.16.0
>
>
> I cannot figure out how to add specific schema to elasticsearch adapter, or 
> how to expose is as the relevant fields with types rather than this weird 
> _MAP, which does not expose correctly for any tool.
> An example or documentation, would help with this issue.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (CALCITE-1958) Cannot create Schema objects when using Avatica with HSQLDB

[Jesus Camacho Rodriguez (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CALCITE-1958?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jesus Camacho Rodriguez updated CALCITE-1958:
-
Fix Version/s: 1.16.0

> Cannot create Schema objects when using Avatica with HSQLDB
> ---
>
> Key: CALCITE-1958
> URL: https://issues.apache.org/jira/browse/CALCITE-1958
> Project: Calcite
>  Issue Type: Bug
>  Components: avatica
>Reporter: Francis Chuang
>Priority: Major
> Fix For: 1.16.0
>
>
> Encountered this one while porting a test from Phoenix to Avatica with HSQLDB 
> for the Go client.
> This happens whether I open the connection with or without a default schema 
> to Avatica.
> I then create a schema: `CREATE SCHEMA IF NOT EXISTS avaticatest`.
> I then attempt to create a table:
> {code}
> CREATE TABLE avaticatest.some_table (
>   int INTEGER PRIMARY KEY
> )
> {code}
> Avatica fails with this message: 
> {code}
> An error was encountered while processing your request: RuntimeException: 
> java.sql.SQLException: invalid schema name: avaticatest in statement [CREATE 
> TABLE avaticatest.some_table (
> int INTEGER PRIMARY KEY
> )] -> SQLException: invalid 
> schema name: avaticatest in statement [CREATE TABLE avaticatest.some_table (
> int INTEGER PRIMARY KEY
> )] -> HsqlException: invalid 
> schema name: avaticatest
> {code}
> I have tried a few things that did not work:
> - Making the schema name uppercase `AVATICATEST` everywhere
> - Making the table name also uppercase everywhere: `SOME_TABLE`.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (CALCITE-2103) error logical plan when size of In-list connected with OR exceeds inSubQueryThreshold

[Jesus Camacho Rodriguez (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CALCITE-2103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jesus Camacho Rodriguez updated CALCITE-2103:
-
Fix Version/s: 1.16.0

> error logical plan when size of In-list connected with OR exceeds 
> inSubQueryThreshold
> -
>
> Key: CALCITE-2103
> URL: https://issues.apache.org/jira/browse/CALCITE-2103
> Project: Calcite
>  Issue Type: Bug
>Reporter: godfrey he
>Assignee: Julian Hyde
>Priority: Major
> Fix For: 1.16.0
>
>
> {code:borderStyle=solid}
> inSubQueryThreshold = 3
> {code}
> SQL：
> {code:borderStyle=solid}
> SELECT * FROM emp AS e WHERE e.empno in (130, 131, 132, 133, 134) OR e.ename 
> in ('a', 'b', 'c', 'd', 'e')
> {code}
> logical plan：
> {code:borderStyle=solid}
> LogicalProject(EMPNO=[$0], ENAME=[$1], JOB=[$2], MGR=[$3], HIREDATE=[$4], 
> SAL=[$5], COMM=[$6], DEPTNO=[$7], SLACKER=[$8])
>   LogicalFilter(condition=[OR(true, true)])
> LogicalJoin(condition=[=($1, $10)], joinType=[inner])
>   LogicalJoin(condition=[=($0, $9)], joinType=[inner])
> LogicalTableScan(table=[[CATALOG, SALES, EMP]])
> LogicalAggregate(group=[{0}])
>   LogicalValues(tuples=[[{ 130 }, { 131 }, { 132 }, { 133 }, { 134 
> }]])
>   LogicalAggregate(group=[{0}])
> LogicalValues(tuples=[[{ 'a' }, { 'b' }, { 'c' }, { 'd' }, { 'e' }]])
> {code}
> the logical plan is wrong.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (CALCITE-2153) SQL parser fails to parse valid multi nested join subqueries

[Jesus Camacho Rodriguez (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CALCITE-2153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jesus Camacho Rodriguez updated CALCITE-2153:
-
Fix Version/s: 1.16.0

> SQL parser fails to parse valid multi nested join subqueries
> 
>
> Key: CALCITE-2153
> URL: https://issues.apache.org/jira/browse/CALCITE-2153
> Project: Calcite
>  Issue Type: Bug
>Reporter: Samuel Waggoner
>Assignee: Julian Hyde
>Priority: Major
> Fix For: 1.16.0
>
>
> I started working on a unit test in SqlParserTest (it's hard to predict exact 
> output, so I just have a placeholder empty string for expectation right now). 
> {code:java}
> @Test public void testInnerJoinOnSubqueryWithAggregation() {
>  final String sql = "select *\n"
>  + "from table1 \n"
>  + "inner join (( \n"
>  + " select * \n"
>  + " from table2 ) \n"
>  + " inner join ( \n"
>  + "   select * \n"
>  + "   from table3) \n"
>  + " on table2.field1 = table3.field1) \n"
>  + "on table1.field1 = table2.field1 \n";
>  sql(sql).ok("");
> }{code}
> I believe this is valid SQL, but parsing fails with this exception
>  
> {code:java}
> java.lang.RuntimeException: Error while parsing SQL: select *
> from table1 
> inner join (( 
>  select * 
>  from table2 ) 
>  inner join ( 
>  select * 
>  from table3) 
>  on table2.field1 = table3.field1) 
> on table1.field1 = table2.field1
>  at 
> org.apache.calcite.sql.parser.SqlParserTest$TesterImpl.parseStmtAndHandleEx(SqlParserTest.java:8201)
>  at 
> org.apache.calcite.sql.parser.SqlParserTest$TesterImpl.check(SqlParserTest.java:8186)
>  at 
> org.apache.calcite.sql.parser.SqlParserTest$Sql.ok(SqlParserTest.java:8384)
>  at 
> org.apache.calcite.sql.parser.SqlParserTest.testInnerJoinOnSubqueryWithAggregation(SqlParserTest.java:8156)
>  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>  at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>  at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>  at java.lang.reflect.Method.invoke(Method.java:498)
>  at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
>  at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>  at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
>  at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>  at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
>  at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
>  at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
>  at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>  at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>  at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
>  at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>  at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
>  at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>  at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
>  at 
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
>  at 
> com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:47)
>  at 
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
>  at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)
> Caused by: org.apache.calcite.sql.parser.SqlParseException: Encountered 
> "inner" at line 6, column 3.
> Was expecting one of:
>  ")" ...
>  "ORDER" ...
>  "LIMIT" ...
>  "OFFSET" ...
>  "FETCH" ...
>  "UNION" ...
>  "INTERSECT" ...
>  "EXCEPT" ...
>  "MINUS" ...
>  "NOT" ...
>  "IN" ...
>  "<" ...
>  "<=" ...
>  ">" ...
>  ">=" ...
>  "=" ...
>  "<>" ...
>  "!=" ...
>  "BETWEEN" ...
>  "LIKE" ...
>  "SIMILAR" ...
>  "+" ...
>  "-" ...
>  "*" ...
>  "/" ...
>  "%" ...
>  "||" ...
>  "AND" ...
>  "OR" ...
>  "IS" ...
>  "MEMBER" ...
>  "SUBMULTISET" ...
>  "CONTAINS" ...
>  "OVERLAPS" ...
>  "EQUALS" ...
>  "PRECEDES" ...
>  "SUCCEEDS" ...
>  "IMMEDIATELY" ...
>  "MULTISET" ...
>  "[" ...
>  "YEAR" ...
>  "MONTH" ...
>  "DAY" ...
>  "HOUR" ...
>  "MINUTE" ...
>  "SECOND" ...
>  
>  at 
> org.apache.calcite.sql.parser.impl.SqlParserImpl.convertException(SqlParserImpl.java:350)
>  at 
> org.apache.calcite.sql.parser.impl.SqlParserImpl.normalizeException(SqlParserImpl.java:131)
>  at org.apache.calcite.sql.parser.SqlParser.parseQuery(SqlParser.java:138)
>  at org.apache.calcite.sql.parser.SqlParser.parseStmt(SqlParser.java:163)
>  at 
> 

[jira] [Updated] (CALCITE-2112) Add Maven wrapper to Calcite

[Jesus Camacho Rodriguez (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CALCITE-2112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jesus Camacho Rodriguez updated CALCITE-2112:
-
Fix Version/s: 1.16.0

> Add Maven wrapper to Calcite
> 
>
> Key: CALCITE-2112
> URL: https://issues.apache.org/jira/browse/CALCITE-2112
> Project: Calcite
>  Issue Type: Improvement
>  Components: build
>Reporter: Ratandeep Ratti
>Assignee: Julian Hyde
>Priority: Major
> Fix For: 1.16.0
>
>
> A Maven wrapper is a nice idea borrowed from Gradle.
> * It makes the project's build fully encapsulated. Users don't have to setup 
> a version of Maven (which could potentially be different than that 
> recommended by Calcite)
> * It also allows Calcite to control the Maven dependency (upgrading to newer 
> versions for example) making it transparent to the user. 
> * Users now will use maven commands as 
> {code}
> ./mvnw clean install
> {code}
> instead
> {code}
> mvn clean install
> {code}
> Presto has done the same -- 
> https://github.com/prestodb/presto/blob/master/mvnw
> It is also extremely easy to setup. See 
> https://github.com/takari/maven-wrapper  . 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (CALCITE-2120) Request to support of Oracle database as meta data store for Druid

[Jesus Camacho Rodriguez (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CALCITE-2120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jesus Camacho Rodriguez updated CALCITE-2120:
-
Fix Version/s: 1.16.0

> Request to support of Oracle database as meta data store for Druid
> --
>
> Key: CALCITE-2120
> URL: https://issues.apache.org/jira/browse/CALCITE-2120
> Project: Calcite
>  Issue Type: New Feature
>  Components: druid
>Reporter: vaibhav
>Assignee: Julian Hyde
>Priority: Major
> Fix For: 1.16.0
>
>
> Currently MySQL, Postgres, and Derby are supported as Druid metadata stores. 
> Request to support of Oracle database as meta data store for Druid.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CALCITE-2181) Release Calcite 1.16.0

[Jesus Camacho Rodriguez (JIRA)]

[ 
https://issues.apache.org/jira/browse/CALCITE-2181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16397779#comment-16397779
 ] 

Jesus Camacho Rodriguez commented on CALCITE-2181:
--

I am creating the RC0 right now. I think CALCITE-2188 or CALCITE-2206 can be 
part of 1.17.0, since they are not blockers for the release.

> Release Calcite 1.16.0
> --
>
> Key: CALCITE-2181
> URL: https://issues.apache.org/jira/browse/CALCITE-2181
> Project: Calcite
>  Issue Type: Task
>Reporter: Jesus Camacho Rodriguez
>Assignee: Jesus Camacho Rodriguez
>Priority: Major
> Fix For: 1.16.0
>
>
> Release Calcite 1.16.0



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (CALCITE-2027) Drop support for Java 7 (JDK 1.7)

[Jesus Camacho Rodriguez (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CALCITE-2027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jesus Camacho Rodriguez resolved CALCITE-2027.
--
Resolution: Fixed

Major subtasks have been completed, closing as fixed. I will change 
{{site/_docs/history.md}} accordingly with new release.

> Drop support for Java 7 (JDK 1.7)
> -
>
> Key: CALCITE-2027
> URL: https://issues.apache.org/jira/browse/CALCITE-2027
> Project: Calcite
>  Issue Type: Bug
>Reporter: Julian Hyde
>Assignee: Julian Hyde
>Priority: Trivial
> Fix For: 1.16.0
>
>
> Drop support for Java 7 (also known as JDK 1.7):
> * The code would no longer compile under JDK 7
> * Compiler would have source 1.8 target 1.8
> * Class files would run on JDK 8 and higher
> * Developers can use Java 8 syntax such as lambdas and default methods
> We would continue to build and run under JDK 8 and 9.
> I think it would be best to wait a while before converting existing code to 
> Java 8 style (e.g. converting SAM anonymous classes to lambdas) because code 
> changes might be extensive.
> I expect there will be cases that we want to change interfaces so that they 
> are easier to use as lambdas. Let's make those changes cautiously when we 
> come across them, and mark existing interfaces and methods deprecated until 
> we remove them in 2.0.
> Let's give at least one release notice of this change. In 1.15 (the next 
> release) let's announce that this will be the last release that supports Java 
> 7. So this will be fixed for 1.16.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (CALCITE-2191) Drop support for Guava versions earlier than 19

[Jesus Camacho Rodriguez (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CALCITE-2191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jesus Camacho Rodriguez resolved CALCITE-2191.
--
Resolution: Fixed

Closing this one as fixed. Will update {{site/_docs/history.md}} accordingly 
with new release.

> Drop support for Guava versions earlier than 19
> ---
>
> Key: CALCITE-2191
> URL: https://issues.apache.org/jira/browse/CALCITE-2191
> Project: Calcite
>  Issue Type: Task
>Reporter: slim bouguerra
>Assignee: Julian Hyde
>Priority: Major
> Fix For: 1.16.0
>
>
> Currently, Calcite-1.15.0 version supports Guava versions from 23 to 14.
> Calcite-1.16.0-Snapshot is building against version 19.0.1 
> As far I know the only reason we support versions earlier to 19 is Hive 
> project depending on Guava 14.0.1 This is not true anymore after 
> https://issues.apache.org/jira/browse/HIVE-15393.
> Druid project is still using Guava 16.0.1 but [some 
> work|https://groups.google.com/forum/#!topic/druid-development/Dw2Qu1CWbuQ] 
> is under review to make sure it is not using deprecated API.   
> Thus I think it is time to Drop support for versions earlier than 19



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CALCITE-2046) Support "CREATE FUNCTION" DDL

[Shuyi Chen (JIRA)]

[ 
https://issues.apache.org/jira/browse/CALCITE-2046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16397769#comment-16397769
 ] 

Shuyi Chen commented on CALCITE-2046:
-

Also keyword  seems to be somehow reserved that I can't use for CREATE 
LIBRARY. I will use  instead. What do you think?

> Support "CREATE FUNCTION" DDL
> -
>
> Key: CALCITE-2046
> URL: https://issues.apache.org/jira/browse/CALCITE-2046
> Project: Calcite
>  Issue Type: New Feature
>Reporter: Shuyi Chen
>Assignee: Shuyi Chen
>Priority: Major
>
> We want to add DDL support for creating external function like Apache Drill 
> ([https://drill.apache.org/docs/create-function-using-jar/]). 
> {code:java}
> CREATE FUNCTION USING JAR '.jar';
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CALCITE-2045) Support "CREATE TYPE" DDL

[Shuyi Chen (JIRA)]

[ 
https://issues.apache.org/jira/browse/CALCITE-2045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16397766#comment-16397766
 ] 

Shuyi Chen commented on CALCITE-2045:
-

Hi [~julianhyde], do you think if we can get this in 1.16? Thanks a lot.

> Support "CREATE TYPE" DDL
> -
>
> Key: CALCITE-2045
> URL: https://issues.apache.org/jira/browse/CALCITE-2045
> Project: Calcite
>  Issue Type: New Feature
>  Components: core
>Reporter: Shuyi Chen
>Assignee: Shuyi Chen
>Priority: Major
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CALCITE-2211) Type of BigInteger should be BIGINT

[Shuyi Chen (JIRA)]

[ 
https://issues.apache.org/jira/browse/CALCITE-2211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16397750#comment-16397750
 ] 

Shuyi Chen commented on CALCITE-2211:
-

Good point. java.math.BigInteger has unlimited decision, I dont think there is 
a sql type equivalent to it. The close I think is decimal. 

In JavaToSqlTypeConversionRules, we are mapping BigDecimal(unlimited precision) 
to Sql.Decimal already, so I think we can convert BigInteger to Sql.Decimal as 
well. Transact-SQL do conversion of integer to Decimal if it's outside the 
integer range. 
(https://docs.microsoft.com/en-us/sql/t-sql/data-types/int-bigint-smallint-and-tinyint-transact-sql#converting-integer-data

> Type of BigInteger should be BIGINT
> ---
>
> Key: CALCITE-2211
> URL: https://issues.apache.org/jira/browse/CALCITE-2211
> Project: Calcite
>  Issue Type: Bug
>Affects Versions: 1.15.0
>Reporter: Eyal Segal
>Assignee: Julian Hyde
>Priority: Major
>
> Vertica DB returns BigInteger values as BigInteger. It seems that 
> JavaToSqlTypeConversionRules doesn't support mapping between BigInteger to 
> BIGINT.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (CALCITE-2207) Enforce Java version via maven-enforcer-plugin

[Jesus Camacho Rodriguez (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CALCITE-2207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jesus Camacho Rodriguez updated CALCITE-2207:
-
Component/s: (was: avatica)

> Enforce Java version via maven-enforcer-plugin
> --
>
> Key: CALCITE-2207
> URL: https://issues.apache.org/jira/browse/CALCITE-2207
> Project: Calcite
>  Issue Type: Task
>  Components: core
>Reporter: Josh Elser
>Assignee: Kevin Risden
>Priority: Critical
> Fix For: 1.16.0
>
>
> Now that jdk7 support has been dropped, we should add some logic to the build 
> to fail obviously when a version of Java is used that we don't support.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (CALCITE-2207) Enforce Java version via maven-enforcer-plugin

[Jesus Camacho Rodriguez (JIRA)]

[ 
https://issues.apache.org/jira/browse/CALCITE-2207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16397742#comment-16397742
 ] 

Jesus Camacho Rodriguez edited comment on CALCITE-2207 at 3/13/18 10:18 PM:


Fixed in http://git-wip-us.apache.org/repos/asf/calcite/commit/75048ff . We can 
fix the avatica bits in CALCITE-2212. Thanks [~risdenk]!


was (Author: jcamachorodriguez):
Fixed in http://git-wip-us.apache.org/repos/asf/calcite/commit/75048ff . We can 
fix the avatica bits in CALCITE-2210. Thanks [~risdenk]!

> Enforce Java version via maven-enforcer-plugin
> --
>
> Key: CALCITE-2207
> URL: https://issues.apache.org/jira/browse/CALCITE-2207
> Project: Calcite
>  Issue Type: Task
>  Components: core
>Reporter: Josh Elser
>Assignee: Kevin Risden
>Priority: Critical
> Fix For: 1.16.0
>
>
> Now that jdk7 support has been dropped, we should add some logic to the build 
> to fail obviously when a version of Java is used that we don't support.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (CALCITE-2212) Avatica - Enforce Java version via maven-enforcer-plugin

[Jesus Camacho Rodriguez (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CALCITE-2212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jesus Camacho Rodriguez updated CALCITE-2212:
-
Component/s: (was: core)

> Avatica - Enforce Java version via maven-enforcer-plugin
> 
>
> Key: CALCITE-2212
> URL: https://issues.apache.org/jira/browse/CALCITE-2212
> Project: Calcite
>  Issue Type: Task
>  Components: avatica
>Reporter: Josh Elser
>Assignee: Kevin Risden
>Priority: Critical
> Fix For: avatica-1.12.0
>
>
> Now that jdk7 support has been dropped, we should add some logic to the build 
> to fail obviously when a version of Java is used that we don't support.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (CALCITE-2212) Avatica - Enforce Java version via maven-enforcer-plugin

[Jesus Camacho Rodriguez (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CALCITE-2212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jesus Camacho Rodriguez updated CALCITE-2212:
-
Fix Version/s: (was: 1.16.0)
   avatica-1.12.0

> Avatica - Enforce Java version via maven-enforcer-plugin
> 
>
> Key: CALCITE-2212
> URL: https://issues.apache.org/jira/browse/CALCITE-2212
> Project: Calcite
>  Issue Type: Task
>  Components: avatica
>Reporter: Josh Elser
>Assignee: Kevin Risden
>Priority: Critical
> Fix For: avatica-1.12.0
>
>
> Now that jdk7 support has been dropped, we should add some logic to the build 
> to fail obviously when a version of Java is used that we don't support.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (CALCITE-2212) Avatica - Enforce Java version via maven-enforcer-plugin

[Jesus Camacho Rodriguez (JIRA)]

Jesus Camacho Rodriguez created CALCITE-2212:


 Summary: Avatica - Enforce Java version via maven-enforcer-plugin
 Key: CALCITE-2212
 URL: https://issues.apache.org/jira/browse/CALCITE-2212
 Project: Calcite
  Issue Type: Task
  Components: avatica, core
Reporter: Josh Elser
Assignee: Kevin Risden
 Fix For: 1.16.0


Now that jdk7 support has been dropped, we should add some logic to the build 
to fail obviously when a version of Java is used that we don't support.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (CALCITE-2207) Enforce Java version via maven-enforcer-plugin

[Jesus Camacho Rodriguez (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CALCITE-2207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jesus Camacho Rodriguez resolved CALCITE-2207.
--
   Resolution: Fixed
Fix Version/s: (was: avatica-1.12.0)

Fixed in http://git-wip-us.apache.org/repos/asf/calcite/commit/75048ff . We can 
fix the avatica bits in CALCITE-2210. Thanks [~risdenk]!

> Enforce Java version via maven-enforcer-plugin
> --
>
> Key: CALCITE-2207
> URL: https://issues.apache.org/jira/browse/CALCITE-2207
> Project: Calcite
>  Issue Type: Task
>  Components: avatica, core
>Reporter: Josh Elser
>Assignee: Kevin Risden
>Priority: Critical
> Fix For: 1.16.0
>
>
> Now that jdk7 support has been dropped, we should add some logic to the build 
> to fail obviously when a version of Java is used that we don't support.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (CALCITE-2020) Upgrade org.incava java-diff

[Jesus Camacho Rodriguez (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CALCITE-2020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jesus Camacho Rodriguez resolved CALCITE-2020.
--
   Resolution: Fixed
Fix Version/s: 1.16.0

Fixed in http://git-wip-us.apache.org/repos/asf/calcite/commit/d134694 . Thanks 
[~julianhyde]!

> Upgrade org.incava java-diff
> 
>
> Key: CALCITE-2020
> URL: https://issues.apache.org/jira/browse/CALCITE-2020
> Project: Calcite
>  Issue Type: Bug
>Reporter: Julian Hyde
>Assignee: Julian Hyde
>Priority: Major
> Fix For: 1.16.0
>
>
> Upgrade org.incava java-diff from 1.1 to 1.1.1.
> The license changed from 2-clause BSD to Apache. The package changed from 
> {{org.incava.util.diff}} to {{org.incava.diff}}.
> The code is on github at https://github.com/jpace/java-diff.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CALCITE-2211) Type of BigInteger should be BIGINT

[Julian Hyde (JIRA)]

[ 
https://issues.apache.org/jira/browse/CALCITE-2211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16397726#comment-16397726
 ] 

Julian Hyde commented on CALCITE-2211:
--

Can you clarify what the Vertica BigInteger type is? In SQL, BIGINT is a 64-bit 
signed integer, same as Java long. The Java java.math.BigInteger type can hold 
signed integers of unlimited precision. So they're not that similar.

> Type of BigInteger should be BIGINT
> ---
>
> Key: CALCITE-2211
> URL: https://issues.apache.org/jira/browse/CALCITE-2211
> Project: Calcite
>  Issue Type: Bug
>Affects Versions: 1.15.0
>Reporter: Eyal Segal
>Assignee: Julian Hyde
>Priority: Major
>
> Vertica DB returns BigInteger values as BigInteger. It seems that 
> JavaToSqlTypeConversionRules doesn't support mapping between BigInteger to 
> BIGINT.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CALCITE-2211) Type of BigInteger should be BIGINT

[Shuyi Chen (JIRA)]

[ 
https://issues.apache.org/jira/browse/CALCITE-2211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16397705#comment-16397705
 ] 

Shuyi Chen commented on CALCITE-2211:
-

It seems we just need to add BigInteger to BIGINT conversion in the map. Do you 
have a unittest that fails? 

> Type of BigInteger should be BIGINT
> ---
>
> Key: CALCITE-2211
> URL: https://issues.apache.org/jira/browse/CALCITE-2211
> Project: Calcite
>  Issue Type: Bug
>Affects Versions: 1.15.0
>Reporter: Eyal Segal
>Assignee: Julian Hyde
>Priority: Major
>
> Vertica DB returns BigInteger values as BigInteger. It seems that 
> JavaToSqlTypeConversionRules doesn't support mapping between BigInteger to 
> BIGINT.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CALCITE-2201) Allow passing custom RelBuilder into RelDecorrelator and RelStructuredTypeFlattener

[Julian Hyde (JIRA)]

[ 
https://issues.apache.org/jira/browse/CALCITE-2201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16397593#comment-16397593
 ] 

Julian Hyde commented on CALCITE-2201:
--

Since they are temporary, non-static, internal rule instances it is sufficient 
to create a RelBuilderFactory that just returns the same RelBuilder. Are there 
any external reasons to pass a RelBuilderFactory rather than RelBuilder? I 
don't think so.

> Allow passing custom RelBuilder into RelDecorrelator and 
> RelStructuredTypeFlattener
> ---
>
> Key: CALCITE-2201
> URL: https://issues.apache.org/jira/browse/CALCITE-2201
> Project: Calcite
>  Issue Type: Task
>Reporter: Volodymyr Vysotskyi
>Assignee: Julian Hyde
>Priority: Major
>
> When {{RelDecorrelator.decorrelateQuery()}} method is called, 
> {{RelDecorrelator}} instance with {{RelFactories.LOGICAL_BUILDER}} is 
> created. We should modify this method to allow usage of custom {{RelBuilder}}.
> Also, {{RelStructuredTypeFlattener}} class should be modified in a similar 
> way.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CALCITE-2201) Allow passing custom RelBuilder into RelDecorrelator and RelStructuredTypeFlattener

[Volodymyr Vysotskyi (JIRA)]

[ 
https://issues.apache.org/jira/browse/CALCITE-2201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16397556#comment-16397556
 ] 

Volodymyr Vysotskyi commented on CALCITE-2201:
--

I'm not sure that it is sufficient since we should pass {{RelBuilderFactory}} 
into the rules constructors which are used in {{RelDecorrelator}}.

> Allow passing custom RelBuilder into RelDecorrelator and 
> RelStructuredTypeFlattener
> ---
>
> Key: CALCITE-2201
> URL: https://issues.apache.org/jira/browse/CALCITE-2201
> Project: Calcite
>  Issue Type: Task
>Reporter: Volodymyr Vysotskyi
>Assignee: Julian Hyde
>Priority: Major
>
> When {{RelDecorrelator.decorrelateQuery()}} method is called, 
> {{RelDecorrelator}} instance with {{RelFactories.LOGICAL_BUILDER}} is 
> created. We should modify this method to allow usage of custom {{RelBuilder}}.
> Also, {{RelStructuredTypeFlattener}} class should be modified in a similar 
> way.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CALCITE-2201) Allow passing custom RelBuilder into RelDecorrelator and RelStructuredTypeFlattener

[Julian Hyde (JIRA)]

[ 
https://issues.apache.org/jira/browse/CALCITE-2201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16397550#comment-16397550
 ] 

Julian Hyde commented on CALCITE-2201:
--

I'm reviewing (and reworking) your latest.

When creating a RelDecorrelator, you now pass a RelBuilderFactory as an 
argument. Am I correct that passing a RelBuilder would be sufficient?

> Allow passing custom RelBuilder into RelDecorrelator and 
> RelStructuredTypeFlattener
> ---
>
> Key: CALCITE-2201
> URL: https://issues.apache.org/jira/browse/CALCITE-2201
> Project: Calcite
>  Issue Type: Task
>Reporter: Volodymyr Vysotskyi
>Assignee: Julian Hyde
>Priority: Major
>
> When {{RelDecorrelator.decorrelateQuery()}} method is called, 
> {{RelDecorrelator}} instance with {{RelFactories.LOGICAL_BUILDER}} is 
> created. We should modify this method to allow usage of custom {{RelBuilder}}.
> Also, {{RelStructuredTypeFlattener}} class should be modified in a similar 
> way.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CALCITE-2207) Enforce Java version via maven-enforcer-plugin

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CALCITE-2207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16397490#comment-16397490
 ] 

ASF GitHub Bot commented on CALCITE-2207:
-

Github user joshelser commented on the issue:

https://github.com/apache/calcite-avatica/pull/30
  
LGTM


> Enforce Java version via maven-enforcer-plugin
> --
>
> Key: CALCITE-2207
> URL: https://issues.apache.org/jira/browse/CALCITE-2207
> Project: Calcite
>  Issue Type: Task
>  Components: avatica, core
>Reporter: Josh Elser
>Assignee: Kevin Risden
>Priority: Critical
> Fix For: 1.16.0, avatica-1.12.0
>
>
> Now that jdk7 support has been dropped, we should add some logic to the build 
> to fail obviously when a version of Java is used that we don't support.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (CALCITE-1737) Support Spark DataFrame And DataSet API

[Linan Zheng (JIRA)]

[ 
https://issues.apache.org/jira/browse/CALCITE-1737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16395815#comment-16395815
 ] 

Linan Zheng edited comment on CALCITE-1737 at 3/13/18 6:36 PM:
---

Hello Everyone,

I am Linan Zheng, a senior student at Boston University and integrating Apache 
Calcite with Spark's DataFrame and DataSet sounds fascinating to me.

I have advanced knowledge with Apache Spark with my previous projects and 
internships as I was responsible for developing an alternative implementation 
for Spark's data structures and ML algorithms. 

For this specific project, if I understand correctly, the goal will be to add 
in DataFrame/DataSet to current Calcite Spark adaptor and I have been going 
through Calcite's documentation and implementation right now. Any advice and 
correction will be greatly appreciated.

Thank you very much!

Linan Zheng


was (Author: lazheng1995):
Hello Everyone,

I am Linan Zheng, a senior student at Boston University and integrating Apache 
Calcite with Spark's DataFrame and DataSet sounds fascinating to me.

I have advanced knowledge with Apache Spark during my previous projects and 
internships as I was responsible for developing an alternative implementation 
for Spark's data structures and ML algorithms. 

For this specific project, if I understand correctly, the goal will be to add 
in DataFrame/DataSet to current Calcite Spark adaptor and I have been going 
through Calcite's documentation and implementation right now. Any advice and 
correction will be greatly appreciated.

Thank you very much!

Linan Zheng

> Support Spark DataFrame And DataSet API
> ---
>
> Key: CALCITE-1737
> URL: https://issues.apache.org/jira/browse/CALCITE-1737
> Project: Calcite
>  Issue Type: Improvement
>  Components: spark
>Reporter: darion yaphet
>Assignee: Julian Hyde
>Priority: Major
>  Labels: gsoc2018
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CALCITE-2201) Allow passing custom RelBuilder into RelDecorrelator and RelStructuredTypeFlattener

[Volodymyr Vysotskyi (JIRA)]

[ 
https://issues.apache.org/jira/browse/CALCITE-2201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16397280#comment-16397280
 ] 

Volodymyr Vysotskyi commented on CALCITE-2201:
--

[~julianhyde], thanks for the review comments! 
I changed the method signatures to pass {{RelBuilder}} instead of 
{{RelBuilderFactory}} where possible and used {{call.builder()}} to receive 
{{RelBuilder}} instance inside rules.
Could you please take a look again?

> Allow passing custom RelBuilder into RelDecorrelator and 
> RelStructuredTypeFlattener
> ---
>
> Key: CALCITE-2201
> URL: https://issues.apache.org/jira/browse/CALCITE-2201
> Project: Calcite
>  Issue Type: Task
>Reporter: Volodymyr Vysotskyi
>Assignee: Julian Hyde
>Priority: Major
>
> When {{RelDecorrelator.decorrelateQuery()}} method is called, 
> {{RelDecorrelator}} instance with {{RelFactories.LOGICAL_BUILDER}} is 
> created. We should modify this method to allow usage of custom {{RelBuilder}}.
> Also, {{RelStructuredTypeFlattener}} class should be modified in a similar 
> way.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (CALCITE-1862) StackOverflowException in RelMdUtil.estimateFilteredRows

[zhen wang (JIRA)]

[ 
https://issues.apache.org/jira/browse/CALCITE-1862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16396947#comment-16396947
 ] 

zhen wang edited comment on CALCITE-1862 at 3/13/18 1:42 PM:
-

removing either  one of the two rules:

{code}
  ProjectFilterTransposeRule.INSTANCE, // removes this generates some 
new issue but no infinitely deep REL problem
  FilterProjectTransposeRule.INSTANCE, // removes this solves this 
problem. 
{code}

so I guess these two optimization rules are fighting against each other in this 
issue. 




was (Author: zhenw):
removing either  one of the two rules:

  ProjectFilterTransposeRule.INSTANCE, // removes this generates some 
new issue but no infinitely deep REL problem
  FilterProjectTransposeRule.INSTANCE, // removes this solves this 
problem. 


so I guess these two optimization rules are fighting against each other in this 
issue. 



> StackOverflowException in RelMdUtil.estimateFilteredRows
> 
>
> Key: CALCITE-1862
> URL: https://issues.apache.org/jira/browse/CALCITE-1862
> Project: Calcite
>  Issue Type: Bug
>Reporter: Julian Hyde
>Assignee: Julian Hyde
>Priority: Major
>
> The query
> {code}select *
> from (
>   select *
>   from (
> select cast(null as integer) as d
> from "scott".emp)
>   where d is null and d is null)
> where d is null;{code}
> gives
> {noformat}
> java.lang.StackOverflowError
> > at 
> > org.apache.calcite.adapter.clone.ArrayTable.getStatistic(ArrayTable.java:76)
> > at 
> > org.apache.calcite.prepare.RelOptTableImpl.getRowCount(RelOptTableImpl.java:224)
> > at 
> > org.apache.calcite.rel.core.TableScan.estimateRowCount(TableScan.java:75)
> > at 
> > org.apache.calcite.rel.metadata.RelMdRowCount.getRowCount(RelMdRowCount.java:206)
> > at GeneratedMetadataHandler_RowCount.getRowCount_$(Unknown Source)
> > at GeneratedMetadataHandler_RowCount.getRowCount(Unknown Source)
> > at 
> > org.apache.calcite.rel.metadata.RelMetadataQuery.getRowCount(RelMetadataQuery.java:236)
> > at 
> > org.apache.calcite.rel.metadata.RelMdRowCount.getRowCount(RelMdRowCount.java:71)
> > at GeneratedMetadataHandler_RowCount.getRowCount_$(Unknown Source)
> > at GeneratedMetadataHandler_RowCount.getRowCount(Unknown Source)
> > at 
> > org.apache.calcite.rel.metadata.RelMetadataQuery.getRowCount(RelMetadataQuery.java:236)
> > at 
> > org.apache.calcite.rel.metadata.RelMdUtil.estimateFilteredRows(RelMdUtil.java:718)
> > at 
> > org.apache.calcite.rel.metadata.RelMdRowCount.getRowCount(RelMdRowCount.java:123)
> > at GeneratedMetadataHandler_RowCount.getRowCount_$(Unknown Source)
> > at GeneratedMetadataHandler_RowCount.getRowCount(Unknown Source)
> > at 
> > org.apache.calcite.rel.metadata.RelMetadataQuery.getRowCount(RelMetadataQuery.java:236)
> > at 
> > org.apache.calcite.rel.metadata.RelMdRowCount.getRowCount(RelMdRowCount.java:71)
> > at GeneratedMetadataHandler_RowCount.getRowCount_$(Unknown Source)
> > at GeneratedMetadataHandler_RowCount.getRowCount(Unknown Source)
> > at 
> > org.apache.calcite.rel.metadata.RelMetadataQuery.getRowCount(RelMetadataQuery.java:236)
> > at 
> > org.apache.calcite.rel.metadata.RelMdUtil.estimateFilteredRows(RelMdUtil.java:718){noformat}
> For a test case, add the query to misc.iq and run QuidemTest.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CALCITE-1862) StackOverflowException in RelMdUtil.estimateFilteredRows

[zhen wang (JIRA)]

[ 
https://issues.apache.org/jira/browse/CALCITE-1862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16396947#comment-16396947
 ] 

zhen wang commented on CALCITE-1862:


removing either  one of the two rules:

  ProjectFilterTransposeRule.INSTANCE, // removes this generates some 
new issue but no infinitely deep REL problem
  FilterProjectTransposeRule.INSTANCE, // removes this solves this 
problem. 


so I guess these two optimization rules are fighting against each other in this 
issue. 



> StackOverflowException in RelMdUtil.estimateFilteredRows
> 
>
> Key: CALCITE-1862
> URL: https://issues.apache.org/jira/browse/CALCITE-1862
> Project: Calcite
>  Issue Type: Bug
>Reporter: Julian Hyde
>Assignee: Julian Hyde
>Priority: Major
>
> The query
> {code}select *
> from (
>   select *
>   from (
> select cast(null as integer) as d
> from "scott".emp)
>   where d is null and d is null)
> where d is null;{code}
> gives
> {noformat}
> java.lang.StackOverflowError
> > at 
> > org.apache.calcite.adapter.clone.ArrayTable.getStatistic(ArrayTable.java:76)
> > at 
> > org.apache.calcite.prepare.RelOptTableImpl.getRowCount(RelOptTableImpl.java:224)
> > at 
> > org.apache.calcite.rel.core.TableScan.estimateRowCount(TableScan.java:75)
> > at 
> > org.apache.calcite.rel.metadata.RelMdRowCount.getRowCount(RelMdRowCount.java:206)
> > at GeneratedMetadataHandler_RowCount.getRowCount_$(Unknown Source)
> > at GeneratedMetadataHandler_RowCount.getRowCount(Unknown Source)
> > at 
> > org.apache.calcite.rel.metadata.RelMetadataQuery.getRowCount(RelMetadataQuery.java:236)
> > at 
> > org.apache.calcite.rel.metadata.RelMdRowCount.getRowCount(RelMdRowCount.java:71)
> > at GeneratedMetadataHandler_RowCount.getRowCount_$(Unknown Source)
> > at GeneratedMetadataHandler_RowCount.getRowCount(Unknown Source)
> > at 
> > org.apache.calcite.rel.metadata.RelMetadataQuery.getRowCount(RelMetadataQuery.java:236)
> > at 
> > org.apache.calcite.rel.metadata.RelMdUtil.estimateFilteredRows(RelMdUtil.java:718)
> > at 
> > org.apache.calcite.rel.metadata.RelMdRowCount.getRowCount(RelMdRowCount.java:123)
> > at GeneratedMetadataHandler_RowCount.getRowCount_$(Unknown Source)
> > at GeneratedMetadataHandler_RowCount.getRowCount(Unknown Source)
> > at 
> > org.apache.calcite.rel.metadata.RelMetadataQuery.getRowCount(RelMetadataQuery.java:236)
> > at 
> > org.apache.calcite.rel.metadata.RelMdRowCount.getRowCount(RelMdRowCount.java:71)
> > at GeneratedMetadataHandler_RowCount.getRowCount_$(Unknown Source)
> > at GeneratedMetadataHandler_RowCount.getRowCount(Unknown Source)
> > at 
> > org.apache.calcite.rel.metadata.RelMetadataQuery.getRowCount(RelMetadataQuery.java:236)
> > at 
> > org.apache.calcite.rel.metadata.RelMdUtil.estimateFilteredRows(RelMdUtil.java:718){noformat}
> For a test case, add the query to misc.iq and run QuidemTest.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (CALCITE-2211) Type of BigInteger should be BIGINT

[Eyal Segal (JIRA)]

Eyal Segal created CALCITE-2211:
---

 Summary: Type of BigInteger should be BIGINT
 Key: CALCITE-2211
 URL: https://issues.apache.org/jira/browse/CALCITE-2211
 Project: Calcite
  Issue Type: Bug
Affects Versions: 1.15.0
Reporter: Eyal Segal
Assignee: Julian Hyde


Vertica DB returns BigInteger values as BigInteger. It seems that 
JavaToSqlTypeConversionRules doesn't support mapping between BigInteger to 
BIGINT.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (CALCITE-2194) Schema access authorization feature

[Piotr Bojko (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CALCITE-2194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Piotr Bojko updated CALCITE-2194:
-
Summary: Schema access authorization feature  (was: Ability to hide a 
schema)

> Schema access authorization feature
> ---
>
> Key: CALCITE-2194
> URL: https://issues.apache.org/jira/browse/CALCITE-2194
> Project: Calcite
>  Issue Type: New Feature
>  Components: core
>Affects Versions: 1.16.0
>Reporter: Piotr Bojko
>Assignee: Piotr Bojko
>Priority: Minor
>
> See: 
> [https://mail-archives.apache.org/mod_mbox/calcite-dev/201711.mbox/ajax/%3C6F6E52D4-6860-4384-A1CB-A2301D05394D%40apache.org%3E]
> I've looked into the core and the notion of an user could be hard to achieved 
> now. 
> Though, I am able to implement the "hidden schema" feature through following 
> changes:
>  # JsonSchema - add a holder for the feature, boolean flag or flags field 
> with enum (CACHED which now exists as a separate flag - some deprecation 
> could be needed, HIDDEN)
>  # CalciteSchema - pass through of a flag
>  # RelOptSchema - pass through of a flag
>  # CalciteCatalogReader - pass through of a flag
>  # Other derivatives of RelOptSchema - mocked value, false
>  # RelOptTable and impl - pass through of a flag
>  # SqlValidatorImpl - validation whether object from hidden schema is used 
> (in the same places like validateAccess)
>  # ViewTableMacro.apply ->  Schemas.analyzeView -> 
> CalcitePrepareImpl.analyzeView -> CalcitePrepareImpl.parse_ -> 
> CalcitePrepareImpl.CalcitePrepareImpl - this path of execution should build 
> SqlValidatorImpl which has the check from point 7 disabled- 
> Such feature could be useful for end users. 
> If the solution is ok - I can contribute it.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CALCITE-1862) StackOverflowException in RelMdUtil.estimateFilteredRows

[zhen wang (JIRA)]

[ 
https://issues.apache.org/jira/browse/CALCITE-1862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16396908#comment-16396908
 ] 

zhen wang commented on CALCITE-1862:


{code} 
before transform: 
EnumerableFilter(condition=[IS NULL(null)])
  EnumerableProject(subset=[rel#44:Subset#5.ENUMERABLE.[]], EMPNO=[$0])
EnumerableFilter(subset=[rel#142:Subset#7.ENUMERABLE.[]], condition=[AND(IS 
NULL(null), IS NULL(null))])
  EnumerableTableScan(subset=[rel#24:Subset#0.ENUMERABLE.[0]], 
table=[[scott, EMP]])

 after transform: 
EnumerableProject(EMPNO=[$0])
  EnumerableFilter(condition=[IS NULL(null)])
EnumerableFilter(subset=[rel#240:Subset#16.ENUMERABLE.[]], condition=[IS 
NULL(null)])
  EnumerableFilter(subset=[rel#234:Subset#15.ENUMERABLE.[]], condition=[IS 
NULL(null)])
EnumerableFilter(subset=[rel#88:Subset#6.ENUMERABLE.[]], condition=[IS 
NULL(null)])
  EnumerableTableScan(subset=[rel#24:Subset#0.ENUMERABLE.[0]], 
table=[[scott, EMP]])
{code}

This occurred when the `Project` relation is a RelSubset, the match process 
didn't choose the best of the Project equivalent RelSubset, but instead chose 
not optimized one. causing the rule to be fired again and again, causing stack 
overflow. 


> StackOverflowException in RelMdUtil.estimateFilteredRows
> 
>
> Key: CALCITE-1862
> URL: https://issues.apache.org/jira/browse/CALCITE-1862
> Project: Calcite
>  Issue Type: Bug
>Reporter: Julian Hyde
>Assignee: Julian Hyde
>Priority: Major
>
> The query
> {code}select *
> from (
>   select *
>   from (
> select cast(null as integer) as d
> from "scott".emp)
>   where d is null and d is null)
> where d is null;{code}
> gives
> {noformat}
> java.lang.StackOverflowError
> > at 
> > org.apache.calcite.adapter.clone.ArrayTable.getStatistic(ArrayTable.java:76)
> > at 
> > org.apache.calcite.prepare.RelOptTableImpl.getRowCount(RelOptTableImpl.java:224)
> > at 
> > org.apache.calcite.rel.core.TableScan.estimateRowCount(TableScan.java:75)
> > at 
> > org.apache.calcite.rel.metadata.RelMdRowCount.getRowCount(RelMdRowCount.java:206)
> > at GeneratedMetadataHandler_RowCount.getRowCount_$(Unknown Source)
> > at GeneratedMetadataHandler_RowCount.getRowCount(Unknown Source)
> > at 
> > org.apache.calcite.rel.metadata.RelMetadataQuery.getRowCount(RelMetadataQuery.java:236)
> > at 
> > org.apache.calcite.rel.metadata.RelMdRowCount.getRowCount(RelMdRowCount.java:71)
> > at GeneratedMetadataHandler_RowCount.getRowCount_$(Unknown Source)
> > at GeneratedMetadataHandler_RowCount.getRowCount(Unknown Source)
> > at 
> > org.apache.calcite.rel.metadata.RelMetadataQuery.getRowCount(RelMetadataQuery.java:236)
> > at 
> > org.apache.calcite.rel.metadata.RelMdUtil.estimateFilteredRows(RelMdUtil.java:718)
> > at 
> > org.apache.calcite.rel.metadata.RelMdRowCount.getRowCount(RelMdRowCount.java:123)
> > at GeneratedMetadataHandler_RowCount.getRowCount_$(Unknown Source)
> > at GeneratedMetadataHandler_RowCount.getRowCount(Unknown Source)
> > at 
> > org.apache.calcite.rel.metadata.RelMetadataQuery.getRowCount(RelMetadataQuery.java:236)
> > at 
> > org.apache.calcite.rel.metadata.RelMdRowCount.getRowCount(RelMdRowCount.java:71)
> > at GeneratedMetadataHandler_RowCount.getRowCount_$(Unknown Source)
> > at GeneratedMetadataHandler_RowCount.getRowCount(Unknown Source)
> > at 
> > org.apache.calcite.rel.metadata.RelMetadataQuery.getRowCount(RelMetadataQuery.java:236)
> > at 
> > org.apache.calcite.rel.metadata.RelMdUtil.estimateFilteredRows(RelMdUtil.java:718){noformat}
> For a test case, add the query to misc.iq and run QuidemTest.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CALCITE-2206) Queries with window functions fail when using HSQLDB

[Pavel Gubin (JIRA)]

[ 
https://issues.apache.org/jira/browse/CALCITE-2206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16396783#comment-16396783
 ] 

Pavel Gubin commented on CALCITE-2206:
--

Why would you want to deprecate the old JdbcConverterRule constructor? It will 
lead to code duplication (specifying default parameter values 10 times in 
JdbcConverterRule subclasses).

Otherwise comments addressed.

> Queries with window functions fail when using HSQLDB
> 
>
> Key: CALCITE-2206
> URL: https://issues.apache.org/jira/browse/CALCITE-2206
> Project: Calcite
>  Issue Type: Bug
>  Components: jdbc-adapter
>Affects Versions: 1.15.0
>Reporter: Pavel Gubin
>Assignee: Julian Hyde
>Priority: Major
>
> Queries containing window functions fail when using HSQLDB (or any other DB 
> that does not support window functions) because optimiser converts them to 
> native SQL with window functions which are not supported by HSQLDB. For 
> example:
> {code:sql}
> select "store_id", "product_id", sum("unit_sales") unit_sales, row_number() 
> over (
> partition by "store_id" order by sum("unit_sales") desc
> ) row_num
> from "sales_fact_1998"
> group by "store_id", "product_id"
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (CALCITE-2206) Queries with window functions fail when using HSQLDB

[Pavel Gubin (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CALCITE-2206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Gubin updated CALCITE-2206:
-
Summary: Queries with window functions fail when using HSQLDB  (was: Window 
functions pushed to JDBC databases regardless of their support)

> Queries with window functions fail when using HSQLDB
> 
>
> Key: CALCITE-2206
> URL: https://issues.apache.org/jira/browse/CALCITE-2206
> Project: Calcite
>  Issue Type: Bug
>  Components: jdbc-adapter
>Affects Versions: 1.15.0
>Reporter: Pavel Gubin
>Assignee: Julian Hyde
>Priority: Major
>
> Queries containing window functions fail when using HSQLDB (or any other DB 
> that does not support window functions) because optimiser converts them to 
> native SQL with window functions which are not supported by HSQLDB. For 
> example:
> {code:sql}
> select "store_id", "product_id", sum("unit_sales") unit_sales, row_number() 
> over (
> partition by "store_id" order by sum("unit_sales") desc
> ) row_num
> from "sales_fact_1998"
> group by "store_id", "product_id"
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)