date:20180522

[jira] [Issue Comment Deleted] (CALCITE-2322) Add fetch size support to connection url and JDBC statement

2018-05-22 Thread Kevin Minder (JIRA)


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

Kevin Minder updated CALCITE-2322:
--
Comment: was deleted

(was: Created pull request: https://github.com/apache/calcite-avatica/pull/49)

> Add fetch size support to connection url and JDBC statement
> ---
>
> Key: CALCITE-2322
> URL: https://issues.apache.org/jira/browse/CALCITE-2322
> Project: Calcite
>  Issue Type: Improvement
>  Components: core
>Affects Versions: 1.11.0
>Reporter: Kevin Minder
>Assignee: Julian Hyde
>Priority: Major
> Attachments: CALCITE-2322.patch
>
>
> Currently the remote driver defaults to hard coded fetch size of 100 rows.  
> When a connection is operating in HTTP mode having such a small fetch size 
> can add enormous overhead.  This is especially true if TLS connections are 
> used and made worse if each connection flows throw multiple proxies.  
> Consider that 100K rows returned 100 rows at a time will make 1K HTTP POST 
> requests.  One might say that nobody should ever do that but some tools like 
> Spotfire may end up doing this.



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

[jira] [Commented] (CALCITE-2322) Add fetch size support to connection url and JDBC statement

2018-05-22 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on CALCITE-2322:
-

GitHub user kminder opened a pull request:

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

CALCITE-2322: Add fetch size support to connection url and JDBC state…

Adds the support for both a URL connection param fetch_size and the JDBD 
Statement API setFetchSize.  This can be used to tune performance for queries 
that return a large number of rows.

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

$ git pull https://github.com/kminder/calcite-avatica 
calcite-2322_add-fetch-size-support-to-connection-url-and-jdbc-statement

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

https://github.com/apache/calcite-avatica/pull/49.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 #49


commit c67cd9ac190532e7255b7936812665999b6e334f
Author: Kevin Minder 
Date:   2018-05-23T01:46:23Z

CALCITE-2322: Add fetch size support to connection url and JDBC statement




> Add fetch size support to connection url and JDBC statement
> ---
>
> Key: CALCITE-2322
> URL: https://issues.apache.org/jira/browse/CALCITE-2322
> Project: Calcite
>  Issue Type: Improvement
>  Components: core
>Affects Versions: 1.11.0
>Reporter: Kevin Minder
>Assignee: Julian Hyde
>Priority: Major
> Attachments: CALCITE-2322.patch
>
>
> Currently the remote driver defaults to hard coded fetch size of 100 rows.  
> When a connection is operating in HTTP mode having such a small fetch size 
> can add enormous overhead.  This is especially true if TLS connections are 
> used and made worse if each connection flows throw multiple proxies.  
> Consider that 100K rows returned 100 rows at a time will make 1K HTTP POST 
> requests.  One might say that nobody should ever do that but some tools like 
> Spotfire may end up doing this.



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

[jira] [Commented] (CALCITE-2322) Add fetch size support to connection url and JDBC statement

2018-05-22 Thread Kevin Minder (JIRA)


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

Kevin Minder commented on CALCITE-2322:
---

Created pull request: https://github.com/apache/calcite-avatica/pull/49

> Add fetch size support to connection url and JDBC statement
> ---
>
> Key: CALCITE-2322
> URL: https://issues.apache.org/jira/browse/CALCITE-2322
> Project: Calcite
>  Issue Type: Improvement
>  Components: core
>Affects Versions: 1.11.0
>Reporter: Kevin Minder
>Assignee: Julian Hyde
>Priority: Major
> Attachments: CALCITE-2322.patch
>
>
> Currently the remote driver defaults to hard coded fetch size of 100 rows.  
> When a connection is operating in HTTP mode having such a small fetch size 
> can add enormous overhead.  This is especially true if TLS connections are 
> used and made worse if each connection flows throw multiple proxies.  
> Consider that 100K rows returned 100 rows at a time will make 1K HTTP POST 
> requests.  One might say that nobody should ever do that but some tools like 
> Spotfire may end up doing this.



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

[jira] [Commented] (CALCITE-2265) Strange cast created for ROW comparison

2018-05-22 Thread Dylan Adams (JIRA)


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

Dylan Adams commented on CALCITE-2265:
--

Rebased and fixed conflicts.

> Strange cast created for ROW comparison
> ---
>
> Key: CALCITE-2265
> URL: https://issues.apache.org/jira/browse/CALCITE-2265
> Project: Calcite
>  Issue Type: Bug
>  Components: core
>Affects Versions: 1.16.0
>Reporter: Dylan Adams
>Assignee: Julian Hyde
>Priority: Major
>
> A comparison using ROWs results in queries that can't be executed by the 
> database due to strange casts like 
> {noformat}
> CAST(ROW('Blake', 'Manager') AS ROW){noformat}
> Direct query against HSQLDB:
>  
> {noformat}
> sqlline>  !connect jdbc:hsqldb:res:scott SCOTT TIGER
> ...
> 0: jdbc:hsqldb:res:scott> SELECT empno FROM emp WHERE (ename, job) < 
> ('Blake', 'Manager');
> ++
> | EMPNO  |
> ++
> | 7499   |
> | 7698   |
> | 7876   |
> ++{noformat}
>  
> Query through calcite:
>  
> {noformat}
> sqlline> !connect 
> jdbc:calcite:schemaType=jdbc;schema.jdbcDriver=org.hsqldb.jdbcDriver;schema.jdbcUrl=jdbc:hsqldb:res:scott;schema.jdbcUser=SCOTT;schema.jdbcPassword=TIGER
>  SCOTT TIGER
> Connecting to 
> jdbc:calcite:schemaType=jdbc;schema.jdbcDriver=org.hsqldb.jdbcDriver;schema.jdbcUrl=jdbc:hsqldb:res:scott;schema.jdbcUser=SCOTT;schema.jdbcPassword=TIGER
> ...
> Connected to: Calcite (version 1.17.0-SNAPSHOT)
> Driver: Calcite JDBC Driver (version 1.17.0-SNAPSHOT)
> Autocommit status: true
> Transaction isolation: TRANSACTION_REPEATABLE_READ
> 0: jdbc:calcite:schemaType=jdbc> SELECT empno FROM emp WHERE (ename, job) < 
> ('Blake', 'Manager');
> Error: Error while executing SQL "SELECT empno FROM emp WHERE (ename, job) < 
> ('Blake', 'Manager')": while executing SQL [SELECT "EMPNO"
> FROM "EMP"
> WHERE ROW("ENAME", "JOB") < CAST(ROW('Blake', 'Manager') AS ROW)] 
> (state=,code=0)
> java.sql.SQLException: Error while executing SQL "SELECT empno FROM emp WHERE 
> (ename, job) < ('Blake', 'Manager')": while executing SQL [SELECT "EMPNO"
> FROM "EMP"
> WHERE ROW("ENAME", "JOB") < CAST(ROW('Blake', 'Manager') AS ROW)]
> at org.apache.calcite.avatica.Helper.createException(Helper.java:56)
> at org.apache.calcite.avatica.Helper.createException(Helper.java:41)
> at 
> org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:156)
> at 
> org.apache.calcite.avatica.AvaticaStatement.execute(AvaticaStatement.java:209)
> at sqlline.Commands.execute(Commands.java:823)
> at sqlline.Commands.sql(Commands.java:733)
> at sqlline.SqlLine.dispatch(SqlLine.java:795)
> at sqlline.SqlLine.begin(SqlLine.java:668)
> at sqlline.SqlLine.start(SqlLine.java:373)
> at sqlline.SqlLine.main(SqlLine.java:265)
> Caused by: java.lang.RuntimeException: while executing SQL [SELECT "EMPNO"
> FROM "EMP"
> WHERE ROW("ENAME", "JOB") < CAST(ROW('Blake', 'Manager') AS ROW)]
> at 
> org.apache.calcite.runtime.ResultSetEnumerable.enumerator(ResultSetEnumerable.java:153)
> at 
> org.apache.calcite.linq4j.AbstractEnumerable.iterator(AbstractEnumerable.java:33)
> at org.apache.calcite.avatica.MetaImpl.createCursor(MetaImpl.java:82)
> at 
> org.apache.calcite.avatica.AvaticaResultSet.execute(AvaticaResultSet.java:174)
> at org.apache.calcite.jdbc.CalciteResultSet.execute(CalciteResultSet.java:67)
> at org.apache.calcite.jdbc.CalciteResultSet.execute(CalciteResultSet.java:44)
> at 
> org.apache.calcite.avatica.AvaticaConnection$1.execute(AvaticaConnection.java:630)
> at 
> org.apache.calcite.jdbc.CalciteMetaImpl.prepareAndExecute(CalciteMetaImpl.java:619)
> at 
> org.apache.calcite.avatica.AvaticaConnection.prepareAndExecuteInternal(AvaticaConnection.java:638)
> at 
> org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:149)
> ... 7 more
> Caused by: java.sql.SQLSyntaxErrorException: type not found or user lacks 
> privilege: ROW
> at org.hsqldb.jdbc.JDBCUtil.sqlException(Unknown Source)
> at org.hsqldb.jdbc.JDBCUtil.sqlException(Unknown Source)
> at org.hsqldb.jdbc.JDBCStatement.fetchResult(Unknown Source)
> at org.hsqldb.jdbc.JDBCStatement.execute(Unknown Source)
> at 
> org.apache.commons.dbcp.DelegatingStatement.execute(DelegatingStatement.java:264)
> at 
> org.apache.commons.dbcp.DelegatingStatement.execute(DelegatingStatement.java:264)
> at 
> org.apache.calcite.runtime.ResultSetEnumerable.enumerator(ResultSetEnumerable.java:143)
> ... 16 more
> Caused by: org.hsqldb.HsqlException: type not found or user lacks privilege: 
> ROW
> at org.hsqldb.error.Error.error(Unknown Source)
> at org.hsqldb.error.Error.error(Unknown Source)
> at org.hsqldb.ParserDQL.readTypeDefinition(Unknown Source)
> at org.hsqldb.ParserDQL.readCastExpressionOrNull(Unknown Source)
> at

[jira] [Commented] (CALCITE-2209) Support loading JSON model file through URL

2018-05-22 Thread Rong Rong (JIRA)


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

Rong Rong commented on CALCITE-2209:


That's a good question. I think ObjectMapper is using openStream method in 
java.net.URL. which is handleded by any instance of java.net.URLStreamHandler 
that handles the particular protocol. 

Digging into the documentation:
 * In most cases, an instance of a {@code URLStreamHandler}
 * subclass is not created directly by an application. Rather, the
 * first time a protocol name is encountered when constructing a
 * {@code URL}, the appropriate stream protocol handler is
 * automatically loaded.

Does that answer your question?

> Support loading JSON model file through URL
> ---
>
> Key: CALCITE-2209
> URL: https://issues.apache.org/jira/browse/CALCITE-2209
> Project: Calcite
>  Issue Type: New Feature
>  Components: core
>Reporter: Shuyi Chen
>Assignee: Shuyi Chen
>Priority: Major
>
> Currently, Calcite only support loading JSON model file through inline or 
> local file. The Jira attemps to extend it to support loading JSON model file 
> through URL, so users can implement their own URLStreamHandlerFactory to read 
> the JSON model file from e.g., HDFS or etc.



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

[jira] [Updated] (CALCITE-2322) Add fetch size support to connection url and JDBC statement

2018-05-22 Thread Kevin Minder (JIRA)


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

Kevin Minder updated CALCITE-2322:
--
Attachment: CALCITE-2322.patch

> Add fetch size support to connection url and JDBC statement
> ---
>
> Key: CALCITE-2322
> URL: https://issues.apache.org/jira/browse/CALCITE-2322
> Project: Calcite
>  Issue Type: Improvement
>  Components: core
>Affects Versions: 1.11.0
>Reporter: Kevin Minder
>Assignee: Julian Hyde
>Priority: Major
> Attachments: CALCITE-2322.patch
>
>
> Currently the remote driver defaults to hard coded fetch size of 100 rows.  
> When a connection is operating in HTTP mode having such a small fetch size 
> can add enormous overhead.  This is especially true if TLS connections are 
> used and made worse if each connection flows throw multiple proxies.  
> Consider that 100K rows returned 100 rows at a time will make 1K HTTP POST 
> requests.  One might say that nobody should ever do that but some tools like 
> Spotfire may end up doing this.



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

[jira] [Updated] (CALCITE-2322) Add fetch size support to connection url and JDBC statement

2018-05-22 Thread Kevin Minder (JIRA)


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

Kevin Minder updated CALCITE-2322:
--
Attachment: (was: calcite-avatica.patch)

> Add fetch size support to connection url and JDBC statement
> ---
>
> Key: CALCITE-2322
> URL: https://issues.apache.org/jira/browse/CALCITE-2322
> Project: Calcite
>  Issue Type: Improvement
>  Components: core
>Affects Versions: 1.11.0
>Reporter: Kevin Minder
>Assignee: Julian Hyde
>Priority: Major
> Attachments: CALCITE-2322.patch
>
>
> Currently the remote driver defaults to hard coded fetch size of 100 rows.  
> When a connection is operating in HTTP mode having such a small fetch size 
> can add enormous overhead.  This is especially true if TLS connections are 
> used and made worse if each connection flows throw multiple proxies.  
> Consider that 100K rows returned 100 rows at a time will make 1K HTTP POST 
> requests.  One might say that nobody should ever do that but some tools like 
> Spotfire may end up doing this.



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

[jira] [Commented] (CALCITE-2322) Add fetch size support to connection url and JDBC statement

2018-05-22 Thread Julian Hyde (JIRA)


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

Julian Hyde commented on CALCITE-2322:
--

We prefer pull requests to patches, if you don't mind.

What are your thoughts on also having a fetch-bytes parameter? (Not necessarily 
as part of this change.) It's frustrating that ODBC and JDBC specify row 
counts, whereas all of the infrastructure between client and server (fixed-size 
buffer, MTU) cares about byte counts. Mapping between the two is not 
straightforward because we don't always have good estimates for row width.

> Add fetch size support to connection url and JDBC statement
> ---
>
> Key: CALCITE-2322
> URL: https://issues.apache.org/jira/browse/CALCITE-2322
> Project: Calcite
>  Issue Type: Improvement
>  Components: core
>Affects Versions: 1.11.0
>Reporter: Kevin Minder
>Assignee: Julian Hyde
>Priority: Major
> Attachments: calcite-avatica.patch
>
>
> Currently the remote driver defaults to hard coded fetch size of 100 rows.  
> When a connection is operating in HTTP mode having such a small fetch size 
> can add enormous overhead.  This is especially true if TLS connections are 
> used and made worse if each connection flows throw multiple proxies.  
> Consider that 100K rows returned 100 rows at a time will make 1K HTTP POST 
> requests.  One might say that nobody should ever do that but some tools like 
> Spotfire may end up doing this.



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

[jira] [Commented] (CALCITE-2322) Add fetch size support to connection url and JDBC statement

2018-05-22 Thread Kevin Minder (JIRA)


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

Kevin Minder commented on CALCITE-2322:
---

I'll have to review your development workflow but I've attached a patch that 
implements this.

> Add fetch size support to connection url and JDBC statement
> ---
>
> Key: CALCITE-2322
> URL: https://issues.apache.org/jira/browse/CALCITE-2322
> Project: Calcite
>  Issue Type: Improvement
>  Components: core
>Affects Versions: 1.11.0
>Reporter: Kevin Minder
>Assignee: Julian Hyde
>Priority: Major
> Attachments: calcite-avatica.patch
>
>
> Currently the remote driver defaults to hard coded fetch size of 100 rows.  
> When a connection is operating in HTTP mode having such a small fetch size 
> can add enormous overhead.  This is especially true if TLS connections are 
> used and made worse if each connection flows throw multiple proxies.  
> Consider that 100K rows returned 100 rows at a time will make 1K HTTP POST 
> requests.  One might say that nobody should ever do that but some tools like 
> Spotfire may end up doing this.



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

[jira] [Updated] (CALCITE-2322) Add fetch size support to connection url and JDBC statement

2018-05-22 Thread Kevin Minder (JIRA)


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

Kevin Minder updated CALCITE-2322:
--
Attachment: calcite-avatica.patch

> Add fetch size support to connection url and JDBC statement
> ---
>
> Key: CALCITE-2322
> URL: https://issues.apache.org/jira/browse/CALCITE-2322
> Project: Calcite
>  Issue Type: Improvement
>  Components: core
>Affects Versions: 1.11.0
>Reporter: Kevin Minder
>Assignee: Julian Hyde
>Priority: Major
> Attachments: calcite-avatica.patch
>
>
> Currently the remote driver defaults to hard coded fetch size of 100 rows.  
> When a connection is operating in HTTP mode having such a small fetch size 
> can add enormous overhead.  This is especially true if TLS connections are 
> used and made worse if each connection flows throw multiple proxies.  
> Consider that 100K rows returned 100 rows at a time will make 1K HTTP POST 
> requests.  One might say that nobody should ever do that but some tools like 
> Spotfire may end up doing this.



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

[jira] [Created] (CALCITE-2322) Add fetch size support to connection url and JDBC statement

2018-05-22 Thread Kevin Minder (JIRA)

Kevin Minder created CALCITE-2322:
-

 Summary: Add fetch size support to connection url and JDBC 
statement
 Key: CALCITE-2322
 URL: https://issues.apache.org/jira/browse/CALCITE-2322
 Project: Calcite
  Issue Type: Improvement
  Components: core
Affects Versions: 1.11.0
Reporter: Kevin Minder
Assignee: Julian Hyde
 Attachments: calcite-avatica.patch

Currently the remote driver defaults to hard coded fetch size of 100 rows.  
When a connection is operating in HTTP mode having such a small fetch size can 
add enormous overhead.  This is especially true if TLS connections are used and 
made worse if each connection flows throw multiple proxies.  Consider that 100K 
rows returned 100 rows at a time will make 1K HTTP POST requests.  One might 
say that nobody should ever do that but some tools like Spotfire may end up 
doing this.



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

[jira] [Commented] (CALCITE-2209) Support loading JSON model file through URL

2018-05-22 Thread Shuyi Chen (JIRA)


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

Shuyi Chen commented on CALCITE-2209:
-

[~walterddr], thanks for the work. Can we dig deeper into how Jackson 
ObjectMapper can be extended and handle other schemas like hdfs:// or custom 
URL schema?

> Support loading JSON model file through URL
> ---
>
> Key: CALCITE-2209
> URL: https://issues.apache.org/jira/browse/CALCITE-2209
> Project: Calcite
>  Issue Type: New Feature
>  Components: core
>Reporter: Shuyi Chen
>Assignee: Shuyi Chen
>Priority: Major
>
> Currently, Calcite only support loading JSON model file through inline or 
> local file. The Jira attemps to extend it to support loading JSON model file 
> through URL, so users can implement their own URLStreamHandlerFactory to read 
> the JSON model file from e.g., HDFS or etc.



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

[jira] [Updated] (CALCITE-2247) Add rule to push conditions into a related disjunctive expression

2018-05-22 Thread Michael Mior (JIRA)


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

Michael Mior updated CALCITE-2247:
--
Summary: Add rule to push conditions into a related disjunctive expression  
(was: Add rule to push in condition condition into a related disjunctive 
expression)

> Add rule to push conditions into a related disjunctive expression
> -
>
> Key: CALCITE-2247
> URL: https://issues.apache.org/jira/browse/CALCITE-2247
> Project: Calcite
>  Issue Type: Improvement
>Reporter: Zoltan Haindrich
>Assignee: Zoltan Haindrich
>Priority: Major
>
> Simplify expressions like: {code}a = 1 AND (a = 1 OR a = 2){code} to {code}a 
> = 1{code}
> Conditions to apply will be:
> * in an AND condition there exists a comparison(c) and an OR (o)
> * o and c only reference 1 variable
> See HIVE-19097 for more info.



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

[jira] [Commented] (CALCITE-2294) Allow customization for AvaticaServerConfiguration for plugging new authentication mechanisms

2018-05-22 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on CALCITE-2294:
-

Github user karanmehta93 commented on the issue:

https://github.com/apache/calcite-avatica/pull/48
  
@joshelser Do you want me to put the edits to the security page as a part 
of this Jira itself?
All I have to do is to modify the `security.md` file, is that correct?


> Allow customization for AvaticaServerConfiguration for plugging new 
> authentication mechanisms
> -
>
> Key: CALCITE-2294
> URL: https://issues.apache.org/jira/browse/CALCITE-2294
> Project: Calcite
>  Issue Type: Improvement
>  Components: avatica
>Reporter: Karan Mehta
>Priority: Major
>
> {{AvaticaServerConfiguration}} is currently only created if authentication 
> mechanism such as {{BASIC, DIGEST or SPNEGO}} is provided. We can change it 
> to a builder pattern to create this object and provide a way for users to 
> plugin their own security configuration.
> An example here can be using it for custom config that supports MTLS.
> Thanks [~alexaraujo] for suggesting this approach.



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

[jira] [Commented] (CALCITE-2294) Allow customization for AvaticaServerConfiguration for plugging new authentication mechanisms

2018-05-22 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on CALCITE-2294:
-

Github user karanmehta93 commented on a diff in the pull request:

https://github.com/apache/calcite-avatica/pull/48#discussion_r189990484
  
--- Diff: 
server/src/main/java/org/apache/calcite/avatica/server/HttpServer.java ---
@@ -239,18 +239,8 @@ protected void internalStart() {
 server.setConnectors(new Connector[] { connector });
 
 // Default to using the handler that was passed in
-final HandlerList handlerList = new HandlerList();
-Handler avaticaHandler = handler;
-
-// Wrap the provided handler for security if we made one
-if (null != securityHandler) {
-  securityHandler.setHandler(handler);
-  avaticaHandler = securityHandler;
-}
+configureHandlers(securityHandler);
--- End diff --

Sure will file a follow up Jira for that.


> Allow customization for AvaticaServerConfiguration for plugging new 
> authentication mechanisms
> -
>
> Key: CALCITE-2294
> URL: https://issues.apache.org/jira/browse/CALCITE-2294
> Project: Calcite
>  Issue Type: Improvement
>  Components: avatica
>Reporter: Karan Mehta
>Priority: Major
>
> {{AvaticaServerConfiguration}} is currently only created if authentication 
> mechanism such as {{BASIC, DIGEST or SPNEGO}} is provided. We can change it 
> to a builder pattern to create this object and provide a way for users to 
> plugin their own security configuration.
> An example here can be using it for custom config that supports MTLS.
> Thanks [~alexaraujo] for suggesting this approach.



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

[jira] [Commented] (CALCITE-2294) Allow customization for AvaticaServerConfiguration for plugging new authentication mechanisms

2018-05-22 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on CALCITE-2294:
-

Github user karanmehta93 commented on a diff in the pull request:

https://github.com/apache/calcite-avatica/pull/48#discussion_r189990372
  
--- Diff: 
server/src/main/java/org/apache/calcite/avatica/server/HttpServer.java ---
@@ -747,6 +758,10 @@ public HttpServer build() {
 }
 serverConfig = buildSpnegoConfiguration(this);
 break;
+  case CUSTOM:
+serverConfig = buildCustomConfiguration(this);
--- End diff --

Okay, Just to clarify, I will keep the same code in place and add the 
comments.


> Allow customization for AvaticaServerConfiguration for plugging new 
> authentication mechanisms
> -
>
> Key: CALCITE-2294
> URL: https://issues.apache.org/jira/browse/CALCITE-2294
> Project: Calcite
>  Issue Type: Improvement
>  Components: avatica
>Reporter: Karan Mehta
>Priority: Major
>
> {{AvaticaServerConfiguration}} is currently only created if authentication 
> mechanism such as {{BASIC, DIGEST or SPNEGO}} is provided. We can change it 
> to a builder pattern to create this object and provide a way for users to 
> plugin their own security configuration.
> An example here can be using it for custom config that supports MTLS.
> Thanks [~alexaraujo] for suggesting this approach.



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

[jira] [Commented] (CALCITE-2129) RelToSqlConverter incorrectly projects aggregate function from sub-query

2018-05-22 Thread Atri Sharma (JIRA)


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

Atri Sharma commented on CALCITE-2129:
--

[~julianhyde] I am hacking this and figured that when we see the subquery's 
aggregate in RelToSqlConverter, we should let be created as an expression and 
not add it to ordinal map. Does that seem like a reasonable rule, please?

> RelToSqlConverter incorrectly projects aggregate function from sub-query
> 
>
> Key: CALCITE-2129
> URL: https://issues.apache.org/jira/browse/CALCITE-2129
> Project: Calcite
>  Issue Type: Bug
>  Components: core, jdbc-adapter
>Affects Versions: 1.15.0
>Reporter: Paul Jackson
>Assignee: Atri Sharma
>Priority: Major
>
> Starting with this DDL:
> {code:SQL}
> create table friends (
>   id int not null,
>   friend_id int,
>   primary key (id),
>   foreign key (friend_id) references friends (id)
> );
> insert into friends values
> (210, null),
> (209, 210),
> (202, 209),
> (208, 202),
> (207, 209),
> (203, 207),
> (201, null),
> (204, null),
> (205, null),
> (206, 209);
> {code}
> This query gives the highest id of friends that share friend_id for each 
> friend:
> {code:SQL}
> SELECT id, friend_id,
>  (SELECT max(f2.id)
>   FROM friends AS f2
>   WHERE f2.friend_id = f1.friend_id) AS foaf_id
> FROM friends AS f1
> idfriend  foaf
> 201   
> 202   209 207
> 203   207 203
> 204   
> 205   
> 206   209 207
> 207   209 207
> 208   202 208
> 209   210 209
> 210
> {code}
> I convert this query to a RelNode and then converted it back to SQL:
> {code:Java}
> Planner aPlanner = Frameworks.getPlanner(aConfig);
> SqlNode aQuery = aPlanner.parse(theSql);
> aQuery = aPlanner.validate(aQuery);
> RelNode aRelNode = aPlanner.rel(aQuery).project();
> RelToSqlConverter aSqlConverter = new RelToSqlConverter(aSqlDialect);
> SqlNode aSqlNode = aSqlConverter.visitChild(0, aRelNode).asStatement();
> {code}
> This gives the following plan and SQL:
> {code}
> LogicalProject(id=[$0], friend_id=[$1], foaf_id=[$2])
>   LogicalProject(id=[$0], friend_id=[$1], EXPR$0=[$3])
> LogicalJoin(condition=[=($1, $2)], joinType=[left])
>   JdbcTableScan(table=[[stardog, friends]])
>   LogicalAggregate(group=[{0}], EXPR$0=[MAX($1)])
> LogicalProject(friend_id=[$1], id=[$0])
>   LogicalProject(id=[$0], friend_id=[$1])
> LogicalFilter(condition=[IS NOT NULL($1)])
>   JdbcTableScan(table=[[stardog, friends]])
> SELECT `friends`.`id`, `friends`.`friend_id`, MAX(`id`)
> FROM `stardog`.`friends`
> LEFT JOIN (SELECT `friend_id`, MAX(`id`)
> FROM `stardog`.`friends`
> WHERE `friend_id` IS NOT NULL
> GROUP BY `friend_id`) AS `t1` ON `friends`.`friend_id` = `t1`.`friend_id`
> {code}
> This is a bad conversion. The {{MAX(`id`)}} should not be repeated in the 
> outer select. PostgreSQL will complain that the aggregating function requires 
> a group by. MySQL returns the max id that has a non-null friend (208), that 
> id's friend (202), and the max id of all rows (210):
> {code}
> idfriend  MAX(`id`)
> 208   202 210
> {code}
> I think the correct SQL should be:
> {code:SQL}
> SELECT `friends`.`id`, `friends`.`friend_id`, foaf_id
> FROM `stardog`.`friends`
> LEFT JOIN (SELECT `friend_id`, MAX(`id`) AS foaf_id
> FROM `stardog`.`friends`
> WHERE `friend_id` IS NOT NULL
> GROUP BY `friend_id`) AS `t1` ON `friends`.`friend_id` = `t1`.`friend_id`
> {code}
> There is code in {{SqlImplementor}} and {{RelToSqlConverter}} that uses an 
> {{ordinalMap}} to track what functions are aliases as what identifiers. When 
> the SQL is generated, the identifier is replaced with the function. If all 
> that code is removed, this works as expected (using {{EXPR$0}} as the alias 
> rather than {{foaf_id}}).



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

[jira] [Issue Comment Deleted] (CALCITE-2129) RelToSqlConverter incorrectly projects aggregate function from sub-query

2018-05-22 Thread Atri Sharma (JIRA)


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

Atri Sharma updated CALCITE-2129:
-
Comment: was deleted

(was: PR: [https://github.com/apache/calcite/pull/695]

 

Please see and let me know)

> RelToSqlConverter incorrectly projects aggregate function from sub-query
> 
>
> Key: CALCITE-2129
> URL: https://issues.apache.org/jira/browse/CALCITE-2129
> Project: Calcite
>  Issue Type: Bug
>  Components: core, jdbc-adapter
>Affects Versions: 1.15.0
>Reporter: Paul Jackson
>Assignee: Atri Sharma
>Priority: Major
>
> Starting with this DDL:
> {code:SQL}
> create table friends (
>   id int not null,
>   friend_id int,
>   primary key (id),
>   foreign key (friend_id) references friends (id)
> );
> insert into friends values
> (210, null),
> (209, 210),
> (202, 209),
> (208, 202),
> (207, 209),
> (203, 207),
> (201, null),
> (204, null),
> (205, null),
> (206, 209);
> {code}
> This query gives the highest id of friends that share friend_id for each 
> friend:
> {code:SQL}
> SELECT id, friend_id,
>  (SELECT max(f2.id)
>   FROM friends AS f2
>   WHERE f2.friend_id = f1.friend_id) AS foaf_id
> FROM friends AS f1
> idfriend  foaf
> 201   
> 202   209 207
> 203   207 203
> 204   
> 205   
> 206   209 207
> 207   209 207
> 208   202 208
> 209   210 209
> 210
> {code}
> I convert this query to a RelNode and then converted it back to SQL:
> {code:Java}
> Planner aPlanner = Frameworks.getPlanner(aConfig);
> SqlNode aQuery = aPlanner.parse(theSql);
> aQuery = aPlanner.validate(aQuery);
> RelNode aRelNode = aPlanner.rel(aQuery).project();
> RelToSqlConverter aSqlConverter = new RelToSqlConverter(aSqlDialect);
> SqlNode aSqlNode = aSqlConverter.visitChild(0, aRelNode).asStatement();
> {code}
> This gives the following plan and SQL:
> {code}
> LogicalProject(id=[$0], friend_id=[$1], foaf_id=[$2])
>   LogicalProject(id=[$0], friend_id=[$1], EXPR$0=[$3])
> LogicalJoin(condition=[=($1, $2)], joinType=[left])
>   JdbcTableScan(table=[[stardog, friends]])
>   LogicalAggregate(group=[{0}], EXPR$0=[MAX($1)])
> LogicalProject(friend_id=[$1], id=[$0])
>   LogicalProject(id=[$0], friend_id=[$1])
> LogicalFilter(condition=[IS NOT NULL($1)])
>   JdbcTableScan(table=[[stardog, friends]])
> SELECT `friends`.`id`, `friends`.`friend_id`, MAX(`id`)
> FROM `stardog`.`friends`
> LEFT JOIN (SELECT `friend_id`, MAX(`id`)
> FROM `stardog`.`friends`
> WHERE `friend_id` IS NOT NULL
> GROUP BY `friend_id`) AS `t1` ON `friends`.`friend_id` = `t1`.`friend_id`
> {code}
> This is a bad conversion. The {{MAX(`id`)}} should not be repeated in the 
> outer select. PostgreSQL will complain that the aggregating function requires 
> a group by. MySQL returns the max id that has a non-null friend (208), that 
> id's friend (202), and the max id of all rows (210):
> {code}
> idfriend  MAX(`id`)
> 208   202 210
> {code}
> I think the correct SQL should be:
> {code:SQL}
> SELECT `friends`.`id`, `friends`.`friend_id`, foaf_id
> FROM `stardog`.`friends`
> LEFT JOIN (SELECT `friend_id`, MAX(`id`) AS foaf_id
> FROM `stardog`.`friends`
> WHERE `friend_id` IS NOT NULL
> GROUP BY `friend_id`) AS `t1` ON `friends`.`friend_id` = `t1`.`friend_id`
> {code}
> There is code in {{SqlImplementor}} and {{RelToSqlConverter}} that uses an 
> {{ordinalMap}} to track what functions are aliases as what identifiers. When 
> the SQL is generated, the identifier is replaced with the function. If all 
> that code is removed, this works as expected (using {{EXPR$0}} as the alias 
> rather than {{foaf_id}}).



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

[jira] [Commented] (CALCITE-2310) SqlParser parse multiple sql statements split by semicolon

2018-05-22 Thread Julian Hyde (JIRA)


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

Julian Hyde commented on CALCITE-2310:
--

The reason I suggest BEGIN ... END is so that the parser knows which syntactic 
construct is coming up. A block (sequence of statements) could even be a kind 
of statement; without BEGIN, a sequence of statements could never be a kind of 
statement.

> SqlParser parse multiple sql statements split by semicolon
> --
>
> Key: CALCITE-2310
> URL: https://issues.apache.org/jira/browse/CALCITE-2310
> Project: Calcite
>  Issue Type: Improvement
>  Components: core
>Reporter: Fei Xu
>Assignee: Julian Hyde
>Priority: Minor
>
> Current, SqlParser only supports parse single sql statement to single 
> SqlNode. But since we have server module, and support DDL syntax, It is 
> common to write DDL statement and DML statement together to build a complete 
> logic. 
> For example:
>  * Table orders is a source table;
>  * Table output_console is a sink table;
>  * Read data from source table, do some project and filter, then write to 
> sink table. 
> {code:java}
> CREATE TABLE orders (
>  createTime TIMESTAMP,
>  productId bigint,
>  orderId bigint,
>  units bigint,
>  user_name VARCHAR
> ); 
> CREATE TABLE output_console(
>  createTime TIMESTAMP,
>  productId bigint,
>  orderId bigint,
>  units bigint,
>  user_name VARCHAR
> );
> INSERT INTO output_console
> SELECT
>  createTime,
>  productId,
>  orderId,
>  units,
>  user_name
> FROM orders
> WHERE (productId>3) AND (productId<8);
> {code}
> So, I think it really helps if SqlParser support parse multiple sql 
> statements.
>  
>  
>  
>  



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

[jira] [Commented] (CALCITE-2130) Converting subquery to join is not always giving equivalent behavior

2018-05-22 Thread Julian Hyde (JIRA)


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

Julian Hyde commented on CALCITE-2130:
--

[~atris] That would be great.

> Converting subquery to join is not always giving equivalent behavior
> 
>
> Key: CALCITE-2130
> URL: https://issues.apache.org/jira/browse/CALCITE-2130
> Project: Calcite
>  Issue Type: Bug
>  Components: core
>Affects Versions: 1.15.0
>Reporter: Paul Jackson
>Assignee: Julian Hyde
>Priority: Major
>
> Starting with this DDL:
> {code:SQL}
> create table friends (
>   id int not null,
>   friend_id int,
>   primary key (id),
>   foreign key (friend_id) references friends (id)
> );
> insert into friends values
> (210, null),
> (209, 210),
> (202, 209),
> (208, 202),
> (207, 209),
> (203, 207),
> (201, null),
> (204, null),
> (205, null),
> (206, 209);
> {code}
> This query looks up a row by id and performs another lookup for id by the 
> friend id:
> {code:SQL}
> SELECT id,
>  (SELECT id
>   FROM friends as f2
>   WHERE f2.friend_id = f1.friend_id) AS friend
> FROM friends as f1
> WHERE id = '203'
> idfriend_id   friend
> 203   207 203
> {code}
> This query only returns a result for rows with unique values for friend_id. 
> Replacing 203 with 202 leads to this error (MySql): {{Error Code: 1242. 
> Subquery returns more than 1 row}}
> I converted this query to a RelNode and then converted it back to SQL using 
> the MySQL dialect:
> {code:Java}
> Planner aPlanner = Frameworks.getPlanner(aConfig);
> SqlNode aQuery = aPlanner.parse(theSql);
> aQuery = aPlanner.validate(aQuery);
> RelNode aRelNode = aPlanner.rel(aQuery).project();
> RelToSqlConverter aSqlConverter = new RelToSqlConverter(aSqlDialect);
> SqlNode aSqlNode = aSqlConverter.visitChild(0, aRelNode).asStatement();
> {code}
> This gives the following plan and SQL:
> {code}
> LogicalProject(id=[$0], friend_id=[$1], friend=[$2])
>   LogicalProject(id=[$0], friend_id=[$1], $f0=[$3])
> LogicalJoin(condition=[=($1, $2)], joinType=[left])
>   LogicalFilter(condition=[=($0, '203')])
> JdbcTableScan(table=[[stardog, friends]])
>   LogicalAggregate(group=[{0}], agg#0=[SINGLE_VALUE($1)])
> LogicalProject(friend_id=[$1], id=[$0])
>   LogicalProject(id=[$0], friend_id=[$1])
> LogicalFilter(condition=[IS NOT NULL($1)])
>   JdbcTableScan(table=[[stardog, friends]])
> SELECT `t`.`id`, `t`.`friend_id`, `t2`.`$f1` AS `$f0`
> FROM (SELECT *
> FROM `stardog`.`friends`
> WHERE `id` = '203') AS `t`
> LEFT JOIN (SELECT `friend_id`, CASE COUNT(`id`) WHEN 0 THEN NULL WHEN 1 THEN 
> `id` ELSE (SELECT NULL
> UNION ALL
> SELECT NULL) END AS `$f1`
> FROM `stardog`.`friends`
> WHERE `friend_id` IS NOT NULL
> GROUP BY `friend_id`) AS `t2` ON `t`.`friend_id` = `t2`.`friend_id`
> {code}
> The MySQL implementation for SINGLE_VALUE is the CASE clause that causes an 
> 1242 error when the id count is greater than 1 by invoking a UNION ALL on two 
> NULL rows. In theory, this should return the ID when it is a unique value and 
> throw an error when there are multiple. Instead, MySQL will return the 1242 
> error for all values of id, including 203.
> Note, the JOIN subquery works if you add a WHERE clause expression to 
> constrain the value of freind_id:
> {code:SQL}
> SELECT `friend_id`, CASE COUNT(`id`) WHEN 0 THEN NULL WHEN 1 THEN `id` ELSE 
> (SELECT NULL
> UNION ALL
> SELECT NULL) END AS `$f1`
> FROM `stardog`.`friends`
> WHERE `friend_id` IS NOT NULL AND `friend_id` = '207'
> GROUP BY `friend_id`
> {code}
> Substituting friend_id for 207 leads to the 1242 error, as intended.
> This JOIN works on some dialects, but I think it is because different 
> dialects can use different join implementations. If the join performs the 
> JOIN ON SELECT clause without adding a where clause expression to constrain 
> friend_id (collecting all rows with a non-null friend_id), it will encounter 
> this error. Implementations that use a join algorithm that does constrain the 
> friend_id to the desired value will experience the error only when there are 
> multiple rows with the same friend_id, which behaves like the original query.



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

[jira] [Commented] (CALCITE-2321) Support ragged fixed length value union be variable

2018-05-22 Thread Julian Hyde (JIRA)


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

Julian Hyde commented on CALCITE-2321:
--

You could apply this behavior during sql-to-rel conversion also. It doesn't 
really have to be part of RelDataTypeSystem or SqlTypeFactoryImpl (even though 
that's where the code lives historically).

I misspoke when I said at it to dialect. Dialect is mainly used for generating 
SQL, not parsing/validating SQL. I think SqlConformance is the best place for 
it.

> Support ragged fixed length value union be variable
> ---
>
> Key: CALCITE-2321
> URL: https://issues.apache.org/jira/browse/CALCITE-2321
> Project: Calcite
>  Issue Type: New Feature
>  Components: core
>Reporter: Hequn Cheng
>Assignee: Hequn Cheng
>Priority: Major
>
> The {{shouldRaggedFixedLengthValueUnionBeVariable()}} function in 
> {{SqlTypeFactoryImpl}} always return false now. It is good to make it 
> configurable since some system may need the function to return true to 
> provide pragmatic behavior. For example, for the sql: case 1 when 1 then 'a' 
> when 2 then 'bcd' end, we need the return value to be 'a' instead of 'a  ' of 
> CHAR(3).
> I see one option to solve this issue: Add {{boolean 
> shouldRaggedFixedLengthValueUnionBeVariable()}} in {{RelDataTypeSystem}}, so 
> external system can override to configure the value.
> Any suggestions are welcomed. Thanks a lot.



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

[jira] [Commented] (CALCITE-2303) Extract for time unit: DECADE not supported!

2018-05-22 Thread Julian Hyde (JIRA)


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

Julian Hyde commented on CALCITE-2303:
--

I quickly reviewed the Avatica change (as of 
[256dd402|https://github.com/apache/calcite-avatica/pull/47/commits/256dd402aa13b0bb8931fdbc56bcf616ca7d5dbb])
 and it looks good. Let's wait until there is a corresponding Calcite change.

(It will take a while, because we will need to make an Avatica release, then 
upgrade Calcite to use that release. That's why it's so important that that we 
test the Avatica in Calcite SQL before we commit the Avatica change.)

> Extract for time unit: DECADE not supported!
> 
>
> Key: CALCITE-2303
> URL: https://issues.apache.org/jira/browse/CALCITE-2303
> Project: Calcite
>  Issue Type: Bug
>Reporter: Sergey Nuyanzin
>Assignee: Julian Hyde
>Priority: Major
>
> Here CALCITE-1177 were supported new units
>  however such test
> {code:java}
>   @Test public void testDecadeFunction() throws Exception {
> ExpressionChecker checker = new ExpressionChecker()
> .addExpr("EXTRACT(DECADE FROM ts)", 199L)
> ;
> checker.buildRunAndCheck();
>   }
> {code}
> failed like
>  Extract for time unit: DECADE not supported!
> {noformat}
> SQL:>
> SELECT EXTRACT(DECADE FROM ts) FROM PCOLLECTION
> May 08, 2018 1:34:58 PM 
> org.apache.beam.sdk.extensions.sql.impl.planner.BeamQueryPlanner 
> validateAndConvert
> INFO: SQL:
> SELECT EXTRACT(DECADE FROM `PCOLLECTION`.`ts`)
> FROM `PCOLLECTION` AS `PCOLLECTION`
> May 08, 2018 1:34:58 PM 
> org.apache.beam.sdk.extensions.sql.impl.planner.BeamQueryPlanner 
> convertToBeamRel
> INFO: SQLPlan>
> LogicalProject(EXPR$0=[EXTRACT(FLAG(DECADE), $0)])
>   BeamIOSourceRel(table=[[PCOLLECTION]])
> java.lang.RuntimeException: 
> org.apache.beam.sdk.Pipeline$PipelineExecutionException: 
> java.lang.UnsupportedOperationException: Extract for time unit: DECADE not 
> supported!
>   at 
> org.apache.beam.sdk.extensions.sql.integrationtest.BeamSqlBuiltinFunctionsIntegrationTestBase$ExpressionChecker.buildRunAndCheck(BeamSqlBuiltinFunctionsIntegrationTestBase.java:167)
>   at 
> org.apache.beam.sdk.extensions.sql.integrationtest.BeamSqlDateFunctionsIntegrationTest.testDecadeFunction(BeamSqlDateFunctionsIntegrationTest.java:66)
>   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.apache.beam.sdk.testing.TestPipeline$1.evaluate(TestPipeline.java:317)
>   at org.junit.rules.RunRules.evaluate(RunRules.java:20)
>   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.beam.sdk.Pipeline$PipelineExecutionException: 
> java.lang.UnsupportedOperationException: Extract for time unit: DECADE not 
> supported!
>   at 
> org.apache.beam.runners.direct.DirectRunner$DirectPipelineResult.waitUntilFinish(DirectRunner.java:349)
>   at 
> org.apache.beam.runners.direct.DirectRunner$DirectPipelineResult.waitUntilFinish(DirectRunner.java:319)
>   at 
>

[jira] [Commented] (CALCITE-2265) Strange cast created for ROW comparison

2018-05-22 Thread Julian Hyde (JIRA)


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

Julian Hyde commented on CALCITE-2265:
--

Can you please rebase on master branch? There are conflicts.

> Strange cast created for ROW comparison
> ---
>
> Key: CALCITE-2265
> URL: https://issues.apache.org/jira/browse/CALCITE-2265
> Project: Calcite
>  Issue Type: Bug
>  Components: core
>Affects Versions: 1.16.0
>Reporter: Dylan Adams
>Assignee: Julian Hyde
>Priority: Major
>
> A comparison using ROWs results in queries that can't be executed by the 
> database due to strange casts like 
> {noformat}
> CAST(ROW('Blake', 'Manager') AS ROW){noformat}
> Direct query against HSQLDB:
>  
> {noformat}
> sqlline>  !connect jdbc:hsqldb:res:scott SCOTT TIGER
> ...
> 0: jdbc:hsqldb:res:scott> SELECT empno FROM emp WHERE (ename, job) < 
> ('Blake', 'Manager');
> ++
> | EMPNO  |
> ++
> | 7499   |
> | 7698   |
> | 7876   |
> ++{noformat}
>  
> Query through calcite:
>  
> {noformat}
> sqlline> !connect 
> jdbc:calcite:schemaType=jdbc;schema.jdbcDriver=org.hsqldb.jdbcDriver;schema.jdbcUrl=jdbc:hsqldb:res:scott;schema.jdbcUser=SCOTT;schema.jdbcPassword=TIGER
>  SCOTT TIGER
> Connecting to 
> jdbc:calcite:schemaType=jdbc;schema.jdbcDriver=org.hsqldb.jdbcDriver;schema.jdbcUrl=jdbc:hsqldb:res:scott;schema.jdbcUser=SCOTT;schema.jdbcPassword=TIGER
> ...
> Connected to: Calcite (version 1.17.0-SNAPSHOT)
> Driver: Calcite JDBC Driver (version 1.17.0-SNAPSHOT)
> Autocommit status: true
> Transaction isolation: TRANSACTION_REPEATABLE_READ
> 0: jdbc:calcite:schemaType=jdbc> SELECT empno FROM emp WHERE (ename, job) < 
> ('Blake', 'Manager');
> Error: Error while executing SQL "SELECT empno FROM emp WHERE (ename, job) < 
> ('Blake', 'Manager')": while executing SQL [SELECT "EMPNO"
> FROM "EMP"
> WHERE ROW("ENAME", "JOB") < CAST(ROW('Blake', 'Manager') AS ROW)] 
> (state=,code=0)
> java.sql.SQLException: Error while executing SQL "SELECT empno FROM emp WHERE 
> (ename, job) < ('Blake', 'Manager')": while executing SQL [SELECT "EMPNO"
> FROM "EMP"
> WHERE ROW("ENAME", "JOB") < CAST(ROW('Blake', 'Manager') AS ROW)]
> at org.apache.calcite.avatica.Helper.createException(Helper.java:56)
> at org.apache.calcite.avatica.Helper.createException(Helper.java:41)
> at 
> org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:156)
> at 
> org.apache.calcite.avatica.AvaticaStatement.execute(AvaticaStatement.java:209)
> at sqlline.Commands.execute(Commands.java:823)
> at sqlline.Commands.sql(Commands.java:733)
> at sqlline.SqlLine.dispatch(SqlLine.java:795)
> at sqlline.SqlLine.begin(SqlLine.java:668)
> at sqlline.SqlLine.start(SqlLine.java:373)
> at sqlline.SqlLine.main(SqlLine.java:265)
> Caused by: java.lang.RuntimeException: while executing SQL [SELECT "EMPNO"
> FROM "EMP"
> WHERE ROW("ENAME", "JOB") < CAST(ROW('Blake', 'Manager') AS ROW)]
> at 
> org.apache.calcite.runtime.ResultSetEnumerable.enumerator(ResultSetEnumerable.java:153)
> at 
> org.apache.calcite.linq4j.AbstractEnumerable.iterator(AbstractEnumerable.java:33)
> at org.apache.calcite.avatica.MetaImpl.createCursor(MetaImpl.java:82)
> at 
> org.apache.calcite.avatica.AvaticaResultSet.execute(AvaticaResultSet.java:174)
> at org.apache.calcite.jdbc.CalciteResultSet.execute(CalciteResultSet.java:67)
> at org.apache.calcite.jdbc.CalciteResultSet.execute(CalciteResultSet.java:44)
> at 
> org.apache.calcite.avatica.AvaticaConnection$1.execute(AvaticaConnection.java:630)
> at 
> org.apache.calcite.jdbc.CalciteMetaImpl.prepareAndExecute(CalciteMetaImpl.java:619)
> at 
> org.apache.calcite.avatica.AvaticaConnection.prepareAndExecuteInternal(AvaticaConnection.java:638)
> at 
> org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:149)
> ... 7 more
> Caused by: java.sql.SQLSyntaxErrorException: type not found or user lacks 
> privilege: ROW
> at org.hsqldb.jdbc.JDBCUtil.sqlException(Unknown Source)
> at org.hsqldb.jdbc.JDBCUtil.sqlException(Unknown Source)
> at org.hsqldb.jdbc.JDBCStatement.fetchResult(Unknown Source)
> at org.hsqldb.jdbc.JDBCStatement.execute(Unknown Source)
> at 
> org.apache.commons.dbcp.DelegatingStatement.execute(DelegatingStatement.java:264)
> at 
> org.apache.commons.dbcp.DelegatingStatement.execute(DelegatingStatement.java:264)
> at 
> org.apache.calcite.runtime.ResultSetEnumerable.enumerator(ResultSetEnumerable.java:143)
> ... 16 more
> Caused by: org.hsqldb.HsqlException: type not found or user lacks privilege: 
> ROW
> at org.hsqldb.error.Error.error(Unknown Source)
> at org.hsqldb.error.Error.error(Unknown Source)
> at org.hsqldb.ParserDQL.readTypeDefinition(Unknown Source)
> at org.hsqldb.ParserDQL.readCastExpressionOrNull(Unknown Source)
> at

[jira] [Commented] (CALCITE-2265) Strange cast created for ROW comparison

2018-05-22 Thread Dylan Adams (JIRA)


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

Dylan Adams commented on CALCITE-2265:
--

It seems like the conversion to the equivalent OR would be good feature to 
have. But it'd be unnecessary for HSQLDB or Postgres, which have good support 
for ROW comparison.

I did a bit of debugging and the cast is being added in 
StandardConvertletTable.convertExpressionList. The types of the two ROW 
operands are RecordType(VARCHAR(10), VARCHAR(9)) and 
RecordType(CHAR(5),CHAR(7)) for the column and literal rows, respectively.

The casts are added because StandardConvertletTable.consistentType doesn't 
consider structs when it checks to see if the input types have the same 
families.

PR: https://github.com/apache/calcite/pull/696

 

> Strange cast created for ROW comparison
> ---
>
> Key: CALCITE-2265
> URL: https://issues.apache.org/jira/browse/CALCITE-2265
> Project: Calcite
>  Issue Type: Bug
>  Components: core
>Affects Versions: 1.16.0
>Reporter: Dylan Adams
>Assignee: Julian Hyde
>Priority: Major
>
> A comparison using ROWs results in queries that can't be executed by the 
> database due to strange casts like 
> {noformat}
> CAST(ROW('Blake', 'Manager') AS ROW){noformat}
> Direct query against HSQLDB:
>  
> {noformat}
> sqlline>  !connect jdbc:hsqldb:res:scott SCOTT TIGER
> ...
> 0: jdbc:hsqldb:res:scott> SELECT empno FROM emp WHERE (ename, job) < 
> ('Blake', 'Manager');
> ++
> | EMPNO  |
> ++
> | 7499   |
> | 7698   |
> | 7876   |
> ++{noformat}
>  
> Query through calcite:
>  
> {noformat}
> sqlline> !connect 
> jdbc:calcite:schemaType=jdbc;schema.jdbcDriver=org.hsqldb.jdbcDriver;schema.jdbcUrl=jdbc:hsqldb:res:scott;schema.jdbcUser=SCOTT;schema.jdbcPassword=TIGER
>  SCOTT TIGER
> Connecting to 
> jdbc:calcite:schemaType=jdbc;schema.jdbcDriver=org.hsqldb.jdbcDriver;schema.jdbcUrl=jdbc:hsqldb:res:scott;schema.jdbcUser=SCOTT;schema.jdbcPassword=TIGER
> ...
> Connected to: Calcite (version 1.17.0-SNAPSHOT)
> Driver: Calcite JDBC Driver (version 1.17.0-SNAPSHOT)
> Autocommit status: true
> Transaction isolation: TRANSACTION_REPEATABLE_READ
> 0: jdbc:calcite:schemaType=jdbc> SELECT empno FROM emp WHERE (ename, job) < 
> ('Blake', 'Manager');
> Error: Error while executing SQL "SELECT empno FROM emp WHERE (ename, job) < 
> ('Blake', 'Manager')": while executing SQL [SELECT "EMPNO"
> FROM "EMP"
> WHERE ROW("ENAME", "JOB") < CAST(ROW('Blake', 'Manager') AS ROW)] 
> (state=,code=0)
> java.sql.SQLException: Error while executing SQL "SELECT empno FROM emp WHERE 
> (ename, job) < ('Blake', 'Manager')": while executing SQL [SELECT "EMPNO"
> FROM "EMP"
> WHERE ROW("ENAME", "JOB") < CAST(ROW('Blake', 'Manager') AS ROW)]
> at org.apache.calcite.avatica.Helper.createException(Helper.java:56)
> at org.apache.calcite.avatica.Helper.createException(Helper.java:41)
> at 
> org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:156)
> at 
> org.apache.calcite.avatica.AvaticaStatement.execute(AvaticaStatement.java:209)
> at sqlline.Commands.execute(Commands.java:823)
> at sqlline.Commands.sql(Commands.java:733)
> at sqlline.SqlLine.dispatch(SqlLine.java:795)
> at sqlline.SqlLine.begin(SqlLine.java:668)
> at sqlline.SqlLine.start(SqlLine.java:373)
> at sqlline.SqlLine.main(SqlLine.java:265)
> Caused by: java.lang.RuntimeException: while executing SQL [SELECT "EMPNO"
> FROM "EMP"
> WHERE ROW("ENAME", "JOB") < CAST(ROW('Blake', 'Manager') AS ROW)]
> at 
> org.apache.calcite.runtime.ResultSetEnumerable.enumerator(ResultSetEnumerable.java:153)
> at 
> org.apache.calcite.linq4j.AbstractEnumerable.iterator(AbstractEnumerable.java:33)
> at org.apache.calcite.avatica.MetaImpl.createCursor(MetaImpl.java:82)
> at 
> org.apache.calcite.avatica.AvaticaResultSet.execute(AvaticaResultSet.java:174)
> at org.apache.calcite.jdbc.CalciteResultSet.execute(CalciteResultSet.java:67)
> at org.apache.calcite.jdbc.CalciteResultSet.execute(CalciteResultSet.java:44)
> at 
> org.apache.calcite.avatica.AvaticaConnection$1.execute(AvaticaConnection.java:630)
> at 
> org.apache.calcite.jdbc.CalciteMetaImpl.prepareAndExecute(CalciteMetaImpl.java:619)
> at 
> org.apache.calcite.avatica.AvaticaConnection.prepareAndExecuteInternal(AvaticaConnection.java:638)
> at 
> org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:149)
> ... 7 more
> Caused by: java.sql.SQLSyntaxErrorException: type not found or user lacks 
> privilege: ROW
> at org.hsqldb.jdbc.JDBCUtil.sqlException(Unknown Source)
> at org.hsqldb.jdbc.JDBCUtil.sqlException(Unknown Source)
> at org.hsqldb.jdbc.JDBCStatement.fetchResult(Unknown Source)
> at org.hsqldb.jdbc.JDBCStatement.execute(Unknown Source)
> at 
>

[jira] [Closed] (CALCITE-2228) An inevitable NPE while using MAX aggregation function

2018-05-22 Thread Muhammad Gelbana (JIRA)


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

Muhammad Gelbana closed CALCITE-2228.
-
Resolution: Duplicate

> An inevitable NPE while using MAX aggregation function
> --
>
> Key: CALCITE-2228
> URL: https://issues.apache.org/jira/browse/CALCITE-2228
> Project: Calcite
>  Issue Type: Bug
>  Components: core
>Affects Versions: 1.16.0
>Reporter: Muhammad Gelbana
>Assignee: Julian Hyde
>Priority: Major
>
> Looking at this 
> [line|https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/interpreter/AggregateNode.java#L150],
>  and the referenced [instance 
> variable|https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/adapter/enumerable/AggImpState.java#L33],
>  it looks to me that
> {code:java}
> int stateSize = agg.state.size{code}
> will always throw a *NPE* because the *agg.state* object reference is never 
> initialized before it's being used !
> I'm facing the following exception
> {noformat}
> java.sql.SQLException: Error while executing SQL "SELECT MAX(COUNTRY_ID), 
> MAX(COUNTRY_TOTAL_ID) FROM SALES.COUNTRIES": null
>     at org.apache.calcite.avatica.Helper.createException(Helper.java:56)
>     at org.apache.calcite.avatica.Helper.createException(Helper.java:41)
>     at 
> org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:156)
>     at 
> org.apache.calcite.avatica.AvaticaStatement.executeQuery(AvaticaStatement.java:218)
>     at 
> com.mg.sqlinterface.data.provider.calcite.internal.Test_SQLi.testMG(Test_SQLi.java:35)
>     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.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>     at 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
>     at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>     at 
> org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:86)
>     at 
> org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
>     at 
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459)
>     at 
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:678)
>     at 
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382)
>     at 
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192)
> Caused by: java.lang.NullPointerException
>     at 
> org.apache.calcite.interpreter.AggregateNode.getAccumulator(AggregateNode.java:150)
>     at 
> org.apache.calcite.interpreter.AggregateNode.(AggregateNode.java:86)
>     at org.apache.calcite.interpreter.Nodes$CoreCompiler.visit(Nodes.java:47)
>     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.apache.calcite.util.ReflectUtil.invokeVisitorInternal(ReflectUtil.java:257)
>     at org.apache.calcite.util.ReflectUtil.invokeVisitor(ReflectUtil.java:214)
>     at 
> org.apache.calcite.util.ReflectUtil$1.invokeVisitor(ReflectUtil.java:464)
>     at 
> org.apache.calcite.interpreter.Interpreter$Compiler.visit(Interpreter.java:480)
>     at 
>

[jira] [Comment Edited] (CALCITE-2321) Support ragged fixed length value union be variable

2018-05-22 Thread Hequn Cheng (JIRA)


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

Hequn Cheng edited comment on CALCITE-2321 at 5/22/18 2:23 PM:
---

Hi [~julianhyde], thanks for your reply. I test Oracle/SqlServer/Mysql and they 
all return the value without blank-padded. Also, it seems that there is no way 
to turn blank-padded on. I found some clear descriptions in mysql reference 
manual: "If all types are character string (CHAR or VARCHAR), the result is 
VARCHAR with maximum length determined by the longest character length of the 
operands". Maybe we should make 
{{shouldRaggedFixedLengthValueUnionBeVariable()}} configurable meanwhile return 
true by default? 

As for creating a type system, other system can create their own type system by 
extending {{RelDataTypeSystemImpl}}, and this may not be a hard work. I tried 
to set it via dialect, but find it is hard to make use of it in 
{{SqlTypeFactoryImpl}} during sql to rel conversion. It seems that dialect is 
used during rel to sql conversion.

Thanks, Hequn


was (Author: hequn8128):
Hi [~julianhyde], thanks for your reply. I test Oracle/SqlServer/Mysql and they 
all return the value without blank-padded. Also, it seems that there is no way 
to turn blank-padded on. Maybe we should make 
{{shouldRaggedFixedLengthValueUnionBeVariable()}} configurable meanwhile return 
true by default? 

As for creating a type system, other system can create their own type system by 
extending {{RelDataTypeSystemImpl}}, and this may not be a hard work. I tried 
to set it via dialect, but find it is hard to make use of it in 
{{SqlTypeFactoryImpl}} during sql to rel conversion. It seems that dialect is 
used during rel to sql conversion.

Thanks, Hequn

> Support ragged fixed length value union be variable
> ---
>
> Key: CALCITE-2321
> URL: https://issues.apache.org/jira/browse/CALCITE-2321
> Project: Calcite
>  Issue Type: New Feature
>  Components: core
>Reporter: Hequn Cheng
>Assignee: Hequn Cheng
>Priority: Major
>
> The {{shouldRaggedFixedLengthValueUnionBeVariable()}} function in 
> {{SqlTypeFactoryImpl}} always return false now. It is good to make it 
> configurable since some system may need the function to return true to 
> provide pragmatic behavior. For example, for the sql: case 1 when 1 then 'a' 
> when 2 then 'bcd' end, we need the return value to be 'a' instead of 'a  ' of 
> CHAR(3).
> I see one option to solve this issue: Add {{boolean 
> shouldRaggedFixedLengthValueUnionBeVariable()}} in {{RelDataTypeSystem}}, so 
> external system can override to configure the value.
> Any suggestions are welcomed. Thanks a lot.



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

[jira] [Commented] (CALCITE-2303) Extract for time unit: DECADE not supported!

2018-05-22 Thread Sergey Nuyanzin (JIRA)


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

Sergey Nuyanzin commented on CALCITE-2303:
--

Ok,   thank you for your comment
currently I updated the PR (avatica only)
now it includes support of extraction for decade, epoch, isodow, isoyear, 
microseconds, milliseconds + fixes for week
also I added more tests

in coming days will do the same for calcite



> Extract for time unit: DECADE not supported!
> 
>
> Key: CALCITE-2303
> URL: https://issues.apache.org/jira/browse/CALCITE-2303
> Project: Calcite
>  Issue Type: Bug
>Reporter: Sergey Nuyanzin
>Assignee: Julian Hyde
>Priority: Major
>
> Here CALCITE-1177 were supported new units
>  however such test
> {code:java}
>   @Test public void testDecadeFunction() throws Exception {
> ExpressionChecker checker = new ExpressionChecker()
> .addExpr("EXTRACT(DECADE FROM ts)", 199L)
> ;
> checker.buildRunAndCheck();
>   }
> {code}
> failed like
>  Extract for time unit: DECADE not supported!
> {noformat}
> SQL:>
> SELECT EXTRACT(DECADE FROM ts) FROM PCOLLECTION
> May 08, 2018 1:34:58 PM 
> org.apache.beam.sdk.extensions.sql.impl.planner.BeamQueryPlanner 
> validateAndConvert
> INFO: SQL:
> SELECT EXTRACT(DECADE FROM `PCOLLECTION`.`ts`)
> FROM `PCOLLECTION` AS `PCOLLECTION`
> May 08, 2018 1:34:58 PM 
> org.apache.beam.sdk.extensions.sql.impl.planner.BeamQueryPlanner 
> convertToBeamRel
> INFO: SQLPlan>
> LogicalProject(EXPR$0=[EXTRACT(FLAG(DECADE), $0)])
>   BeamIOSourceRel(table=[[PCOLLECTION]])
> java.lang.RuntimeException: 
> org.apache.beam.sdk.Pipeline$PipelineExecutionException: 
> java.lang.UnsupportedOperationException: Extract for time unit: DECADE not 
> supported!
>   at 
> org.apache.beam.sdk.extensions.sql.integrationtest.BeamSqlBuiltinFunctionsIntegrationTestBase$ExpressionChecker.buildRunAndCheck(BeamSqlBuiltinFunctionsIntegrationTestBase.java:167)
>   at 
> org.apache.beam.sdk.extensions.sql.integrationtest.BeamSqlDateFunctionsIntegrationTest.testDecadeFunction(BeamSqlDateFunctionsIntegrationTest.java:66)
>   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.apache.beam.sdk.testing.TestPipeline$1.evaluate(TestPipeline.java:317)
>   at org.junit.rules.RunRules.evaluate(RunRules.java:20)
>   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.beam.sdk.Pipeline$PipelineExecutionException: 
> java.lang.UnsupportedOperationException: Extract for time unit: DECADE not 
> supported!
>   at 
> org.apache.beam.runners.direct.DirectRunner$DirectPipelineResult.waitUntilFinish(DirectRunner.java:349)
>   at 
> org.apache.beam.runners.direct.DirectRunner$DirectPipelineResult.waitUntilFinish(DirectRunner.java:319)
>   at 
> org.apache.beam.runners.direct.DirectRunner.run(DirectRunner.java:210)
>   at org.apache.beam.runners.direct.DirectRunner.run(DirectRunner.java:66)
>   at org.apache.beam.sdk.Pipeline.run(Pipeline.java:311)
>

[jira] [Commented] (CALCITE-2321) Support ragged fixed length value union be variable

2018-05-22 Thread Hequn Cheng (JIRA)


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

Hequn Cheng commented on CALCITE-2321:
--

Hi [~julianhyde], thanks for your reply. I test Oracle/SqlServer/Mysql and they 
all return the value without blank-padded. Also, it seems that there is no way 
to turn blank-padded on. Maybe we should make 
{{shouldRaggedFixedLengthValueUnionBeVariable()}} configurable meanwhile return 
true by default? 

As for creating a type system, other system can create their own type system by 
extending {{RelDataTypeSystemImpl}}, and this may not be a hard work. I tried 
to set it via dialect, but find it is hard to make use of it in 
{{SqlTypeFactoryImpl}} during sql to rel conversion. It seems that dialect is 
used during rel to sql conversion.

Thanks, Hequn

> Support ragged fixed length value union be variable
> ---
>
> Key: CALCITE-2321
> URL: https://issues.apache.org/jira/browse/CALCITE-2321
> Project: Calcite
>  Issue Type: New Feature
>  Components: core
>Reporter: Hequn Cheng
>Assignee: Hequn Cheng
>Priority: Major
>
> The {{shouldRaggedFixedLengthValueUnionBeVariable()}} function in 
> {{SqlTypeFactoryImpl}} always return false now. It is good to make it 
> configurable since some system may need the function to return true to 
> provide pragmatic behavior. For example, for the sql: case 1 when 1 then 'a' 
> when 2 then 'bcd' end, we need the return value to be 'a' instead of 'a  ' of 
> CHAR(3).
> I see one option to solve this issue: Add {{boolean 
> shouldRaggedFixedLengthValueUnionBeVariable()}} in {{RelDataTypeSystem}}, so 
> external system can override to configure the value.
> Any suggestions are welcomed. Thanks a lot.



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

[jira] [Assigned] (CALCITE-2320) UDF in WHERE expression incorrectly pushed down to jdbc schema

2018-05-22 Thread Piotr Bojko (JIRA)


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

Piotr Bojko reassigned CALCITE-2320:


Assignee: Piotr Bojko  (was: Julian Hyde)

> UDF in WHERE expression incorrectly pushed down to jdbc schema
> --
>
> Key: CALCITE-2320
> URL: https://issues.apache.org/jira/browse/CALCITE-2320
> Project: Calcite
>  Issue Type: Bug
>Affects Versions: 1.16.0, 1.17.0
>Reporter: Piotr Bojko
>Assignee: Piotr Bojko
>Priority: Major
> Fix For: 1.17.0
>
>
> # Checks whether CHOOSENCUSTOMFUNCTION function is properly computed and not 
> passed to subschema, like jdbc
> SELECT * FROM SIMPLE_CUSTOMER WHERE email = CHOOSENCUSTOMER();
> where CHOOSENCUSTOMER is UDF leads to 
> {code}
>  Caused by: java.lang.RuntimeException: while executing SQL [SELECT 
> "FIRSTNAME", "LASTNAME", "EMAIL"
> > FROM "CUSTOMER"
> > WHERE "EMAIL" = "CHOOSENCUSTOMER"()]
> > at 
> > org.apache.calcite.runtime.ResultSetEnumerable.enumerator(ResultSetEnumerable.java:153)
> > at 
> > org.apache.calcite.linq4j.AbstractEnumerable.iterator(AbstractEnumerable.java:33)
> > at org.apache.calcite.avatica.MetaImpl.createCursor(MetaImpl.java:90)
> > at 
> > org.apache.calcite.avatica.AvaticaResultSet.execute(AvaticaResultSet.java:174)
> > at 
> > org.apache.calcite.jdbc.CalciteResultSet.execute(CalciteResultSet.java:67)
> > at 
> > org.apache.calcite.jdbc.CalciteResultSet.execute(CalciteResultSet.java:44)
> > at 
> > org.apache.calcite.avatica.AvaticaConnection$1.execute(AvaticaConnection.java:630)
> > at 
> > org.apache.calcite.jdbc.CalciteMetaImpl.prepareAndExecute(CalciteMetaImpl.java:619)
> > at 
> > org.apache.calcite.avatica.AvaticaConnection.prepareAndExecuteInternal(AvaticaConnection.java:638)
> > at 
> > org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:149)
> > ... 24 more
> > Caused by: java.sql.SQLSyntaxErrorException: user lacks privilege or object 
> > not found: CHOOSENCUSTOMER
> > at org.hsqldb.jdbc.JDBCUtil.sqlException(Unknown Source)
> > at org.hsqldb.jdbc.JDBCUtil.sqlException(Unknown Source)
> > at org.hsqldb.jdbc.JDBCStatement.fetchResult(Unknown Source)
> > at org.hsqldb.jdbc.JDBCStatement.execute(Unknown Source)
> > at 
> > org.apache.commons.dbcp.DelegatingStatement.execute(DelegatingStatement.java:264)
> > at 
> > org.apache.commons.dbcp.DelegatingStatement.execute(DelegatingStatement.java:264)
> > at 
> > org.apache.calcite.runtime.ResultSetEnumerable.enumerator(ResultSetEnumerable.java:143)
> > ... 33 more
> > Caused by: org.hsqldb.HsqlException: user lacks privilege or object not 
> > found: CHOOSENCUSTOMER
> > at org.hsqldb.error.Error.error(Unknown Source)
> > at org.hsqldb.error.Error.error(Unknown Source)
> > at org.hsqldb.Routine.getMethods(Unknown Source)
> > at org.hsqldb.Routine.createRoutines(Unknown Source)
> > at org.hsqldb.ParserDQL.readColumnOrFunctionExpression(Unknown Source)
> > at org.hsqldb.ParserDQL.XreadSimpleValueExpressionPrimary(Unknown 
> > Source)
> > at org.hsqldb.ParserDQL.XreadAllTypesValueExpressionPrimary(Unknown 
> > Source)
> > at org.hsqldb.ParserDQL.XreadAllTypesPrimary(Unknown Source)
> > at org.hsqldb.ParserDQL.XreadAllTypesFactor(Unknown Source)
> > at org.hsqldb.ParserDQL.XreadAllTypesTerm(Unknown Source)
> > at org.hsqldb.ParserDQL.XreadAllTypesCommonValueExpression(Unknown 
> > Source)
> > at org.hsqldb.ParserDQL.XreadRowOrCommonValueExpression(Unknown Source)
> > at org.hsqldb.ParserDQL.XreadRowValuePredicand(Unknown Source)
> > at org.hsqldb.ParserDQL.XreadPredicateRightPart(Unknown Source)
> > at org.hsqldb.ParserDQL.XreadBooleanPrimaryOrNull(Unknown Source)
> {code}



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

[jira] [Updated] (CALCITE-2317) getFunctions() showing empty

2018-05-22 Thread Subbarao (JIRA)


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

Subbarao updated CALCITE-2317:
--
Attachment: CalciteWithOracle.java

> getFunctions() showing empty
> 
>
> Key: CALCITE-2317
> URL: https://issues.apache.org/jira/browse/CALCITE-2317
> Project: Calcite
>  Issue Type: Bug
>Reporter: Subbarao
>Assignee: Julian Hyde
>Priority: Major
> Attachments: CalciteWithOracle.java
>
>
> how to get all function names and procedure names in oracle database using 
> calcite connection and schema.
> schema.getFunctionNames() return result is:[ ]
> Then i am try to retrieving DatabaseMetadata.getFunction().Here also it will 
> be showing empty.
> Iam using calciResultSet ,AvaticaResultSet and ResultSet for getting 
> functions and procedures but will be showing empty.
> Is it possible get all function names and procedure names from any database.
> But normal jdbc connection using DatabseMetaData properties  it retrive alll 
> function names and procedure names.Why it will not retrive in calcite



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

[jira] [Issue Comment Deleted] (CALCITE-2322) Add fetch size support to connection url and JDBC statement

[jira] [Commented] (CALCITE-2322) Add fetch size support to connection url and JDBC statement

[jira] [Commented] (CALCITE-2322) Add fetch size support to connection url and JDBC statement

[jira] [Commented] (CALCITE-2265) Strange cast created for ROW comparison

[jira] [Commented] (CALCITE-2209) Support loading JSON model file through URL

[jira] [Updated] (CALCITE-2322) Add fetch size support to connection url and JDBC statement

[jira] [Updated] (CALCITE-2322) Add fetch size support to connection url and JDBC statement

[jira] [Commented] (CALCITE-2322) Add fetch size support to connection url and JDBC statement

[jira] [Commented] (CALCITE-2322) Add fetch size support to connection url and JDBC statement

[jira] [Updated] (CALCITE-2322) Add fetch size support to connection url and JDBC statement

[jira] [Created] (CALCITE-2322) Add fetch size support to connection url and JDBC statement

[jira] [Commented] (CALCITE-2209) Support loading JSON model file through URL

[jira] [Updated] (CALCITE-2247) Add rule to push conditions into a related disjunctive expression

[jira] [Commented] (CALCITE-2294) Allow customization for AvaticaServerConfiguration for plugging new authentication mechanisms

[jira] [Commented] (CALCITE-2294) Allow customization for AvaticaServerConfiguration for plugging new authentication mechanisms

[jira] [Commented] (CALCITE-2294) Allow customization for AvaticaServerConfiguration for plugging new authentication mechanisms

[jira] [Commented] (CALCITE-2129) RelToSqlConverter incorrectly projects aggregate function from sub-query

[jira] [Issue Comment Deleted] (CALCITE-2129) RelToSqlConverter incorrectly projects aggregate function from sub-query

[jira] [Commented] (CALCITE-2310) SqlParser parse multiple sql statements split by semicolon

[jira] [Commented] (CALCITE-2130) Converting subquery to join is not always giving equivalent behavior

[jira] [Commented] (CALCITE-2321) Support ragged fixed length value union be variable

[jira] [Commented] (CALCITE-2303) Extract for time unit: DECADE not supported!

[jira] [Commented] (CALCITE-2265) Strange cast created for ROW comparison

[jira] [Commented] (CALCITE-2265) Strange cast created for ROW comparison

[jira] [Closed] (CALCITE-2228) An inevitable NPE while using MAX aggregation function

[jira] [Comment Edited] (CALCITE-2321) Support ragged fixed length value union be variable

[jira] [Commented] (CALCITE-2303) Extract for time unit: DECADE not supported!

[jira] [Commented] (CALCITE-2321) Support ragged fixed length value union be variable

[jira] [Assigned] (CALCITE-2320) UDF in WHERE expression incorrectly pushed down to jdbc schema

[jira] [Updated] (CALCITE-2317) getFunctions() showing empty

30 matches

Site Navigation

Mail list logo

Footer information