[jira] [Created] (CALCITE-5792) Update dependencies to latest version

2023-06-21 Thread Parag Jain (Jira)
Parag Jain created CALCITE-5792:
---

 Summary: Update dependencies to latest version
 Key: CALCITE-5792
 URL: https://issues.apache.org/jira/browse/CALCITE-5792
 Project: Calcite
  Issue Type: Bug
  Components: avatica-go
Reporter: Parag Jain
Assignee: Francis Chuang


Update dependencies to latest version



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Commented] (CALCITE-5719) Issues with connection and authentication with Apache Druid

2023-06-05 Thread Parag Jain (Jira)


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

Parag Jain commented on CALCITE-5719:
-

Thanks raised issues and respective PRs here - 
https://issues.apache.org/jira/browse/CALCITE-5752, 
https://issues.apache.org/jira/browse/CALCITE-5753, 
https://issues.apache.org/jira/browse/CALCITE-5754 

> Issues with connection and authentication with Apache Druid
> ---
>
> Key: CALCITE-5719
> URL: https://issues.apache.org/jira/browse/CALCITE-5719
> Project: Calcite
>  Issue Type: Bug
>  Components: avatica-go
>Reporter: Parag Jain
>Assignee: Francis Chuang
>Priority: Major
>  Labels: avatica
>
> We are using calcite-avatica-go driver to connect to Apache Druid and facing 
> few issues -
>  # In Go sql package when an idle connection is picked from the pool, 
> *ResetSession* method is called on the connection. In the drivers 
> implementation of this method 
> [here|https://github.com/apache/calcite-avatica-go/blob/main/connection.go#L236],
>  *registerConn* method is called which actually does an 
> *OpenConnectionRequest* with the existing connectionId. On the Druid side it 
> actually throws an exception 
> [here|https://github.com/apache/druid/blob/master/sql/src/main/java/org/apache/druid/sql/avatica/DruidMeta.java#L823]
>  saying the connection is already open. I checked other driver 
> implementations like 
> [postgres|https://github.com/jackc/pgx/blob/master/stdlib/sql.go#L307] and 
> [mysql|https://github.com/go-sql-driver/mysql/blob/master/connection.go#L638] 
> for ResetSession method and they actually don't open a new connection. So not 
> sure about the reason for doing this here. Any thoughts on this ? Example 
> exception stack trace -
> {code:java}
> 2023-05-22T19:24:47,357 ERROR [qtp44562-140] 
> org.apache.druid.sql.avatica.DruidMeta - Connection 
> [fcf73260-cb72-b867-154b-e39a19569c5e] already open.
> org.apache.druid.java.util.common.ISE: Connection 
> [fcf73260-cb72-b867-154b-e39a19569c5e] already open.
>     at 
> org.apache.druid.sql.avatica.DruidMeta.openDruidConnection(DruidMeta.java:823)
>  ~[classes/:?]
>     at 
> org.apache.druid.sql.avatica.DruidMeta.openConnection(DruidMeta.java:208) 
> ~[classes/:?]
>     at 
> org.apache.calcite.avatica.remote.LocalService.apply(LocalService.java:285) 
> ~[avatica-core-1.17.0.jar:1.17.0]
>     at 
> org.apache.calcite.avatica.remote.Service$OpenConnectionRequest.accept(Service.java:1770)
>  ~[avatica-core-1.17.0.jar:1.17.0]
>     at 
> org.apache.calcite.avatica.remote.Service$OpenConnectionRequest.accept(Service.java:1750)
>  ~[avatica-core-1.17.0.jar:1.17.0]
>     at 
> org.apache.calcite.avatica.remote.AbstractHandler.apply(AbstractHandler.java:94)
>  ~[avatica-core-1.17.0.jar:1.17.0]
>     at 
> org.apache.calcite.avatica.remote.ProtobufHandler.apply(ProtobufHandler.java:46)
>  ~[avatica-core-1.17.0.jar:1.17.0]
>     at 
> org.apache.calcite.avatica.server.AvaticaProtobufHandler.handle(AvaticaProtobufHandler.java:126)
>  ~[avatica-server-1.17.0.jar:1.17.0]
>     at 
> org.apache.druid.sql.avatica.DruidAvaticaProtobufHandler.handle(DruidAvaticaProtobufHandler.java:61)
>  ~[classes/:?] {code}
>     2. Username and pwd not being propagated in the JDBC context. Had to add 
> the following code in the 
> [Connect|https://github.com/apache/calcite-avatica-go/blob/main/driver.go#L64]
>  method of driver.go to make it work
> {code:java}
>     if config.avaticaUser != "" {
>         c.Info["user"] = config.avaticaUser
>     }
>     if config.avaticaPassword != "" {
>         c.Info["password"] = config.avaticaPassword
>     }  {code}
>     3. My colleague (Benjamin) found open statement leak as well, fixed 
> [here|https://github.com/apache/calcite-avatica-go/commit/9c0eba2fbe15b3f877ee276b889cbd39e1a8ce2d]
>  We plan to contribute all back once the issues are fixed.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Commented] (CALCITE-5754) Open statement leak in avatica go driver

2023-06-05 Thread Parag Jain (Jira)


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

Parag Jain commented on CALCITE-5754:
-

Fixed here - https://github.com/apache/calcite-avatica-go/pull/66

> Open statement leak in avatica go driver
> 
>
> Key: CALCITE-5754
> URL: https://issues.apache.org/jira/browse/CALCITE-5754
> Project: Calcite
>  Issue Type: Bug
>  Components: avatica-go
>Affects Versions: 1.34.0
>Reporter: Parag Jain
>Assignee: Francis Chuang
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
>  My colleague (Benjamin) found open statement leak in the code where 
> statement close request is not sent to the database after query is executed 
> in exec and query methods in connection.go



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Created] (CALCITE-5754) Open statement leak in avatica go driver

2023-06-05 Thread Parag Jain (Jira)
Parag Jain created CALCITE-5754:
---

 Summary: Open statement leak in avatica go driver
 Key: CALCITE-5754
 URL: https://issues.apache.org/jira/browse/CALCITE-5754
 Project: Calcite
  Issue Type: Bug
  Components: avatica-go
Affects Versions: 1.34.0
Reporter: Parag Jain
Assignee: Francis Chuang


 My colleague (Benjamin) found open statement leak in the code where statement 
close request is not sent to the database after query is executed in exec and 
query methods in connection.go



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Commented] (CALCITE-5753) User and pwd not being propagated to JDBC context from go driver

2023-06-05 Thread Parag Jain (Jira)


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

Parag Jain commented on CALCITE-5753:
-

PR - https://github.com/apache/calcite-avatica-go/pull/65

> User and pwd not being propagated to JDBC context from go driver
> 
>
> Key: CALCITE-5753
> URL: https://issues.apache.org/jira/browse/CALCITE-5753
> Project: Calcite
>  Issue Type: Bug
>  Components: avatica-go
>Affects Versions: 1.34.0
>Reporter: Parag Jain
>Assignee: Francis Chuang
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Username and pwd not being propagated in the JDBC context. Had to add the 
> following code in the 
> [Connect|https://github.com/apache/calcite-avatica-go/blob/main/driver.go#L64]
>  method of driver.go to make it work
> {code:java}
>     if config.avaticaUser != "" {
>         c.Info["user"] = config.avaticaUser
>     }
>     if config.avaticaPassword != "" {
>         c.Info["password"] = config.avaticaPassword
>     }  {code}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Created] (CALCITE-5753) User and pwd not being propagated to JDBC context from go driver

2023-06-05 Thread Parag Jain (Jira)
Parag Jain created CALCITE-5753:
---

 Summary: User and pwd not being propagated to JDBC context from go 
driver
 Key: CALCITE-5753
 URL: https://issues.apache.org/jira/browse/CALCITE-5753
 Project: Calcite
  Issue Type: Bug
  Components: avatica-go
Affects Versions: 1.34.0
Reporter: Parag Jain
Assignee: Francis Chuang


Username and pwd not being propagated in the JDBC context. Had to add the 
following code in the 
[Connect|https://github.com/apache/calcite-avatica-go/blob/main/driver.go#L64] 
method of driver.go to make it work
{code:java}
    if config.avaticaUser != "" {
        c.Info["user"] = config.avaticaUser
    }
    if config.avaticaPassword != "" {
        c.Info["password"] = config.avaticaPassword
    }  {code}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Commented] (CALCITE-5752) Error during session reset in avatica go driver

2023-06-05 Thread Parag Jain (Jira)


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

Parag Jain commented on CALCITE-5752:
-

Fix here - https://github.com/apache/calcite-avatica-go/pull/64

> Error during session reset in avatica go driver
> ---
>
> Key: CALCITE-5752
> URL: https://issues.apache.org/jira/browse/CALCITE-5752
> Project: Calcite
>  Issue Type: Bug
>  Components: avatica-go
>Affects Versions: 1.34.0
>Reporter: Parag Jain
>Assignee: Francis Chuang
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> In Go sql package when an idle connection is picked from the pool, 
> *ResetSession* method is called on the connection. In the drivers 
> implementation of this method 
> [here|https://github.com/apache/calcite-avatica-go/blob/main/connection.go#L236],
>  *registerConn* method is called which actually does an 
> *OpenConnectionRequest* with the existing connectionId. On the Druid side it 
> actually throws an exception 
> [here|https://github.com/apache/druid/blob/master/sql/src/main/java/org/apache/druid/sql/avatica/DruidMeta.java#L823]
>  saying the connection is already open. I checked other driver 
> implementations like 
> [postgres|https://github.com/jackc/pgx/blob/master/stdlib/sql.go#L307] and 
> [mysql|https://github.com/go-sql-driver/mysql/blob/master/connection.go#L638] 
> for ResetSession method and they actually don't open a new connection. So not 
> sure about the reason for doing this here. Any thoughts on this ? Example 
> exception stack trace -
> {code:java}
> 2023-05-22T19:24:47,357 ERROR [qtp44562-140] 
> org.apache.druid.sql.avatica.DruidMeta - Connection 
> [fcf73260-cb72-b867-154b-e39a19569c5e] already open.
> org.apache.druid.java.util.common.ISE: Connection 
> [fcf73260-cb72-b867-154b-e39a19569c5e] already open.
>     at 
> org.apache.druid.sql.avatica.DruidMeta.openDruidConnection(DruidMeta.java:823)
>  ~[classes/:?]
>     at 
> org.apache.druid.sql.avatica.DruidMeta.openConnection(DruidMeta.java:208) 
> ~[classes/:?]
>     at 
> org.apache.calcite.avatica.remote.LocalService.apply(LocalService.java:285) 
> ~[avatica-core-1.17.0.jar:1.17.0]
>     at 
> org.apache.calcite.avatica.remote.Service$OpenConnectionRequest.accept(Service.java:1770)
>  ~[avatica-core-1.17.0.jar:1.17.0]
>     at 
> org.apache.calcite.avatica.remote.Service$OpenConnectionRequest.accept(Service.java:1750)
>  ~[avatica-core-1.17.0.jar:1.17.0]
>     at 
> org.apache.calcite.avatica.remote.AbstractHandler.apply(AbstractHandler.java:94)
>  ~[avatica-core-1.17.0.jar:1.17.0]
>     at 
> org.apache.calcite.avatica.remote.ProtobufHandler.apply(ProtobufHandler.java:46)
>  ~[avatica-core-1.17.0.jar:1.17.0]
>     at 
> org.apache.calcite.avatica.server.AvaticaProtobufHandler.handle(AvaticaProtobufHandler.java:126)
>  ~[avatica-server-1.17.0.jar:1.17.0]
>     at 
> org.apache.druid.sql.avatica.DruidAvaticaProtobufHandler.handle(DruidAvaticaProtobufHandler.java:61)
>  ~[classes/:?] {code}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Created] (CALCITE-5752) Error during session reset in avatica go driver

2023-06-05 Thread Parag Jain (Jira)
Parag Jain created CALCITE-5752:
---

 Summary: Error during session reset in avatica go driver
 Key: CALCITE-5752
 URL: https://issues.apache.org/jira/browse/CALCITE-5752
 Project: Calcite
  Issue Type: Bug
  Components: avatica-go
Affects Versions: 1.34.0
Reporter: Parag Jain
Assignee: Francis Chuang


In Go sql package when an idle connection is picked from the pool, 
*ResetSession* method is called on the connection. In the drivers 
implementation of this method 
[here|https://github.com/apache/calcite-avatica-go/blob/main/connection.go#L236],
 *registerConn* method is called which actually does an *OpenConnectionRequest* 
with the existing connectionId. On the Druid side it actually throws an 
exception 
[here|https://github.com/apache/druid/blob/master/sql/src/main/java/org/apache/druid/sql/avatica/DruidMeta.java#L823]
 saying the connection is already open. I checked other driver implementations 
like [postgres|https://github.com/jackc/pgx/blob/master/stdlib/sql.go#L307] and 
[mysql|https://github.com/go-sql-driver/mysql/blob/master/connection.go#L638] 
for ResetSession method and they actually don't open a new connection. So not 
sure about the reason for doing this here. Any thoughts on this ? Example 
exception stack trace -
{code:java}
2023-05-22T19:24:47,357 ERROR [qtp44562-140] 
org.apache.druid.sql.avatica.DruidMeta - Connection 
[fcf73260-cb72-b867-154b-e39a19569c5e] already open.
org.apache.druid.java.util.common.ISE: Connection 
[fcf73260-cb72-b867-154b-e39a19569c5e] already open.
    at 
org.apache.druid.sql.avatica.DruidMeta.openDruidConnection(DruidMeta.java:823) 
~[classes/:?]
    at 
org.apache.druid.sql.avatica.DruidMeta.openConnection(DruidMeta.java:208) 
~[classes/:?]
    at 
org.apache.calcite.avatica.remote.LocalService.apply(LocalService.java:285) 
~[avatica-core-1.17.0.jar:1.17.0]
    at 
org.apache.calcite.avatica.remote.Service$OpenConnectionRequest.accept(Service.java:1770)
 ~[avatica-core-1.17.0.jar:1.17.0]
    at 
org.apache.calcite.avatica.remote.Service$OpenConnectionRequest.accept(Service.java:1750)
 ~[avatica-core-1.17.0.jar:1.17.0]
    at 
org.apache.calcite.avatica.remote.AbstractHandler.apply(AbstractHandler.java:94)
 ~[avatica-core-1.17.0.jar:1.17.0]
    at 
org.apache.calcite.avatica.remote.ProtobufHandler.apply(ProtobufHandler.java:46)
 ~[avatica-core-1.17.0.jar:1.17.0]
    at 
org.apache.calcite.avatica.server.AvaticaProtobufHandler.handle(AvaticaProtobufHandler.java:126)
 ~[avatica-server-1.17.0.jar:1.17.0]
    at 
org.apache.druid.sql.avatica.DruidAvaticaProtobufHandler.handle(DruidAvaticaProtobufHandler.java:61)
 ~[classes/:?] {code}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Commented] (CALCITE-5719) Issues with connection and authentication with Apache Druid

2023-05-28 Thread Parag Jain (Jira)


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

Parag Jain commented on CALCITE-5719:
-

[~francischuang] Any thoughts/comments?

> Issues with connection and authentication with Apache Druid
> ---
>
> Key: CALCITE-5719
> URL: https://issues.apache.org/jira/browse/CALCITE-5719
> Project: Calcite
>  Issue Type: Bug
>  Components: avatica-go
>Reporter: Parag Jain
>Assignee: Francis Chuang
>Priority: Major
>  Labels: avatica
>
> We are using calcite-avatica-go driver to connect to Apache Druid and facing 
> few issues -
>  # In Go sql package when an idle connection is picked from the pool, 
> *ResetSession* method is called on the connection. In the drivers 
> implementation of this method 
> [here|https://github.com/apache/calcite-avatica-go/blob/main/connection.go#L236],
>  *registerConn* method is called which actually does an 
> *OpenConnectionRequest* with the existing connectionId. On the Druid side it 
> actually throws an exception 
> [here|https://github.com/apache/druid/blob/master/sql/src/main/java/org/apache/druid/sql/avatica/DruidMeta.java#L823]
>  saying the connection is already open. I checked other driver 
> implementations like 
> [postgres|https://github.com/jackc/pgx/blob/master/stdlib/sql.go#L307] and 
> [mysql|https://github.com/go-sql-driver/mysql/blob/master/connection.go#L638] 
> for ResetSession method and they actually don't open a new connection. So not 
> sure about the reason for doing this here. Any thoughts on this ? Example 
> exception stack trace -
> {code:java}
> 2023-05-22T19:24:47,357 ERROR [qtp44562-140] 
> org.apache.druid.sql.avatica.DruidMeta - Connection 
> [fcf73260-cb72-b867-154b-e39a19569c5e] already open.
> org.apache.druid.java.util.common.ISE: Connection 
> [fcf73260-cb72-b867-154b-e39a19569c5e] already open.
>     at 
> org.apache.druid.sql.avatica.DruidMeta.openDruidConnection(DruidMeta.java:823)
>  ~[classes/:?]
>     at 
> org.apache.druid.sql.avatica.DruidMeta.openConnection(DruidMeta.java:208) 
> ~[classes/:?]
>     at 
> org.apache.calcite.avatica.remote.LocalService.apply(LocalService.java:285) 
> ~[avatica-core-1.17.0.jar:1.17.0]
>     at 
> org.apache.calcite.avatica.remote.Service$OpenConnectionRequest.accept(Service.java:1770)
>  ~[avatica-core-1.17.0.jar:1.17.0]
>     at 
> org.apache.calcite.avatica.remote.Service$OpenConnectionRequest.accept(Service.java:1750)
>  ~[avatica-core-1.17.0.jar:1.17.0]
>     at 
> org.apache.calcite.avatica.remote.AbstractHandler.apply(AbstractHandler.java:94)
>  ~[avatica-core-1.17.0.jar:1.17.0]
>     at 
> org.apache.calcite.avatica.remote.ProtobufHandler.apply(ProtobufHandler.java:46)
>  ~[avatica-core-1.17.0.jar:1.17.0]
>     at 
> org.apache.calcite.avatica.server.AvaticaProtobufHandler.handle(AvaticaProtobufHandler.java:126)
>  ~[avatica-server-1.17.0.jar:1.17.0]
>     at 
> org.apache.druid.sql.avatica.DruidAvaticaProtobufHandler.handle(DruidAvaticaProtobufHandler.java:61)
>  ~[classes/:?] {code}
>     2. Username and pwd not being propagated in the JDBC context. Had to add 
> the following code in the 
> [Connect|https://github.com/apache/calcite-avatica-go/blob/main/driver.go#L64]
>  method of driver.go to make it work
> {code:java}
>     if config.avaticaUser != "" {
>         c.Info["user"] = config.avaticaUser
>     }
>     if config.avaticaPassword != "" {
>         c.Info["password"] = config.avaticaPassword
>     }  {code}
>     3. My colleague (Benjamin) found open statement leak as well, fixed 
> [here|https://github.com/apache/calcite-avatica-go/commit/9c0eba2fbe15b3f877ee276b889cbd39e1a8ce2d]
>  We plan to contribute all back once the issues are fixed.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Updated] (CALCITE-5719) Issues with connection and authentication with Apache Druid

2023-05-22 Thread Parag Jain (Jira)


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

Parag Jain updated CALCITE-5719:

Description: 
We are using calcite-avatica-go driver to connect to Apache Druid and facing 
few issues -
 # In Go sql package when an idle connection is picked from the pool, 
*ResetSession* method is called on the connection. In the drivers 
implementation of this method 
[here|https://github.com/apache/calcite-avatica-go/blob/main/connection.go#L236],
 *registerConn* method is called which actually does an *OpenConnectionRequest* 
with the existing connectionId. On the Druid side it actually throws an 
exception 
[here|https://github.com/apache/druid/blob/master/sql/src/main/java/org/apache/druid/sql/avatica/DruidMeta.java#L823]
 saying the connection is already open. I checked other driver implementations 
like [postgres|https://github.com/jackc/pgx/blob/master/stdlib/sql.go#L307] and 
[mysql|https://github.com/go-sql-driver/mysql/blob/master/connection.go#L638] 
for ResetSession method and they actually don't open a new connection. So not 
sure about the reason for doing this here. Any thoughts on this ? Example 
exception stack trace -
{code:java}
2023-05-22T19:24:47,357 ERROR [qtp44562-140] 
org.apache.druid.sql.avatica.DruidMeta - Connection 
[fcf73260-cb72-b867-154b-e39a19569c5e] already open.
org.apache.druid.java.util.common.ISE: Connection 
[fcf73260-cb72-b867-154b-e39a19569c5e] already open.
    at 
org.apache.druid.sql.avatica.DruidMeta.openDruidConnection(DruidMeta.java:823) 
~[classes/:?]
    at 
org.apache.druid.sql.avatica.DruidMeta.openConnection(DruidMeta.java:208) 
~[classes/:?]
    at 
org.apache.calcite.avatica.remote.LocalService.apply(LocalService.java:285) 
~[avatica-core-1.17.0.jar:1.17.0]
    at 
org.apache.calcite.avatica.remote.Service$OpenConnectionRequest.accept(Service.java:1770)
 ~[avatica-core-1.17.0.jar:1.17.0]
    at 
org.apache.calcite.avatica.remote.Service$OpenConnectionRequest.accept(Service.java:1750)
 ~[avatica-core-1.17.0.jar:1.17.0]
    at 
org.apache.calcite.avatica.remote.AbstractHandler.apply(AbstractHandler.java:94)
 ~[avatica-core-1.17.0.jar:1.17.0]
    at 
org.apache.calcite.avatica.remote.ProtobufHandler.apply(ProtobufHandler.java:46)
 ~[avatica-core-1.17.0.jar:1.17.0]
    at 
org.apache.calcite.avatica.server.AvaticaProtobufHandler.handle(AvaticaProtobufHandler.java:126)
 ~[avatica-server-1.17.0.jar:1.17.0]
    at 
org.apache.druid.sql.avatica.DruidAvaticaProtobufHandler.handle(DruidAvaticaProtobufHandler.java:61)
 ~[classes/:?] {code}

    2. Username and pwd not being propagated in the JDBC context. Had to add 
the following code in the 
[Connect|https://github.com/apache/calcite-avatica-go/blob/main/driver.go#L64] 
method of driver.go to make it work
{code:java}
    if config.avaticaUser != "" {
        c.Info["user"] = config.avaticaUser
    }
    if config.avaticaPassword != "" {
        c.Info["password"] = config.avaticaPassword
    }  {code}
    3. My colleague (Benjamin) found open statement leak as well, fixed 
[here|[https://github.com/apache/calcite-avatica-go/commit/9c0eba2fbe15b3f877ee276b889cbd39e1a8ce2d]]
 We plan to contribute all back once the issues are fixed.

  was:
We are using calcite-avatica-go driver to connect to Apache Druid and facing 
few issues -
 # In Go sql package when an idle connection is picked from the pool, 
*ResetSession* method is called on the connection. In the drivers 
implementation of this method 
[here|https://github.com/apache/calcite-avatica-go/blob/main/connection.go#L236],
 *registerConn* method is called which actually does an *OpenConnectionRequest* 
with the existing connectionId. On the Druid side it actually throws an 
exception 
[here|https://github.com/apache/druid/blob/master/sql/src/main/java/org/apache/druid/sql/avatica/DruidMeta.java#L823]
 saying the connection is already open. I checked other driver implementations 
like [postgres|https://github.com/jackc/pgx/blob/master/stdlib/sql.go#L307] and 
[mysql|https://github.com/go-sql-driver/mysql/blob/master/connection.go#L638] 
for ResetSession method and they actually don't open a new connection. So not 
sure about the reason for doing this here. Any thoughts on this ? Example 
exception stack trace -
{code:java}
2023-05-22T19:24:47,357 ERROR [qtp44562-140] 
org.apache.druid.sql.avatica.DruidMeta - Connection 
[fcf73260-cb72-b867-154b-e39a19569c5e] already open.
org.apache.druid.java.util.common.ISE: Connection 
[fcf73260-cb72-b867-154b-e39a19569c5e] already open.
    at 
org.apache.druid.sql.avatica.DruidMeta.openDruidConnection(DruidMeta.java:823) 
~[classes/:?]
    at 
org.apache.druid.sql.avatica.DruidMeta.openConnection(DruidMeta.java:208) 
~[classes/:?]
    at 
org.apache.calcite.avatica.remote.LocalService.apply(LocalService.java:285) 
~[avatica-core-1.17.0.jar:1.17.0]
    at 

[jira] [Updated] (CALCITE-5719) Issues with connection and authentication with Apache Druid

2023-05-22 Thread Parag Jain (Jira)


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

Parag Jain updated CALCITE-5719:

Description: 
We are using calcite-avatica-go driver to connect to Apache Druid and facing 
few issues -
 # In Go sql package when an idle connection is picked from the pool, 
*ResetSession* method is called on the connection. In the drivers 
implementation of this method 
[here|https://github.com/apache/calcite-avatica-go/blob/main/connection.go#L236],
 *registerConn* method is called which actually does an *OpenConnectionRequest* 
with the existing connectionId. On the Druid side it actually throws an 
exception 
[here|https://github.com/apache/druid/blob/master/sql/src/main/java/org/apache/druid/sql/avatica/DruidMeta.java#L823]
 saying the connection is already open. I checked other driver implementations 
like [postgres|https://github.com/jackc/pgx/blob/master/stdlib/sql.go#L307] and 
[mysql|https://github.com/go-sql-driver/mysql/blob/master/connection.go#L638] 
for ResetSession method and they actually don't open a new connection. So not 
sure about the reason for doing this here. Any thoughts on this ? Example 
exception stack trace -
{code:java}
2023-05-22T19:24:47,357 ERROR [qtp44562-140] 
org.apache.druid.sql.avatica.DruidMeta - Connection 
[fcf73260-cb72-b867-154b-e39a19569c5e] already open.
org.apache.druid.java.util.common.ISE: Connection 
[fcf73260-cb72-b867-154b-e39a19569c5e] already open.
    at 
org.apache.druid.sql.avatica.DruidMeta.openDruidConnection(DruidMeta.java:823) 
~[classes/:?]
    at 
org.apache.druid.sql.avatica.DruidMeta.openConnection(DruidMeta.java:208) 
~[classes/:?]
    at 
org.apache.calcite.avatica.remote.LocalService.apply(LocalService.java:285) 
~[avatica-core-1.17.0.jar:1.17.0]
    at 
org.apache.calcite.avatica.remote.Service$OpenConnectionRequest.accept(Service.java:1770)
 ~[avatica-core-1.17.0.jar:1.17.0]
    at 
org.apache.calcite.avatica.remote.Service$OpenConnectionRequest.accept(Service.java:1750)
 ~[avatica-core-1.17.0.jar:1.17.0]
    at 
org.apache.calcite.avatica.remote.AbstractHandler.apply(AbstractHandler.java:94)
 ~[avatica-core-1.17.0.jar:1.17.0]
    at 
org.apache.calcite.avatica.remote.ProtobufHandler.apply(ProtobufHandler.java:46)
 ~[avatica-core-1.17.0.jar:1.17.0]
    at 
org.apache.calcite.avatica.server.AvaticaProtobufHandler.handle(AvaticaProtobufHandler.java:126)
 ~[avatica-server-1.17.0.jar:1.17.0]
    at 
org.apache.druid.sql.avatica.DruidAvaticaProtobufHandler.handle(DruidAvaticaProtobufHandler.java:61)
 ~[classes/:?] {code}

    2. Username and pwd not being propagated in the JDBC context. Had to add 
the following code in the 
[Connect|https://github.com/apache/calcite-avatica-go/blob/main/driver.go#L64] 
method of driver.go to make it work
{code:java}
    if config.avaticaUser != "" {
        c.Info["user"] = config.avaticaUser
    }
    if config.avaticaPassword != "" {
        c.Info["password"] = config.avaticaPassword
    }  {code}
    3. My colleague (Benjamin) found open statement leak as well, fixed 
[here|https://github.com/apache/calcite-avatica-go/commit/9c0eba2fbe15b3f877ee276b889cbd39e1a8ce2d]
 We plan to contribute all back once the issues are fixed.

  was:
We are using calcite-avatica-go driver to connect to Apache Druid and facing 
few issues -
 # In Go sql package when an idle connection is picked from the pool, 
*ResetSession* method is called on the connection. In the drivers 
implementation of this method 
[here|https://github.com/apache/calcite-avatica-go/blob/main/connection.go#L236],
 *registerConn* method is called which actually does an *OpenConnectionRequest* 
with the existing connectionId. On the Druid side it actually throws an 
exception 
[here|https://github.com/apache/druid/blob/master/sql/src/main/java/org/apache/druid/sql/avatica/DruidMeta.java#L823]
 saying the connection is already open. I checked other driver implementations 
like [postgres|https://github.com/jackc/pgx/blob/master/stdlib/sql.go#L307] and 
[mysql|https://github.com/go-sql-driver/mysql/blob/master/connection.go#L638] 
for ResetSession method and they actually don't open a new connection. So not 
sure about the reason for doing this here. Any thoughts on this ? Example 
exception stack trace -
{code:java}
2023-05-22T19:24:47,357 ERROR [qtp44562-140] 
org.apache.druid.sql.avatica.DruidMeta - Connection 
[fcf73260-cb72-b867-154b-e39a19569c5e] already open.
org.apache.druid.java.util.common.ISE: Connection 
[fcf73260-cb72-b867-154b-e39a19569c5e] already open.
    at 
org.apache.druid.sql.avatica.DruidMeta.openDruidConnection(DruidMeta.java:823) 
~[classes/:?]
    at 
org.apache.druid.sql.avatica.DruidMeta.openConnection(DruidMeta.java:208) 
~[classes/:?]
    at 
org.apache.calcite.avatica.remote.LocalService.apply(LocalService.java:285) 
~[avatica-core-1.17.0.jar:1.17.0]
    at 

[jira] [Updated] (CALCITE-5719) Issues with connection and authentication with Apache Druid

2023-05-22 Thread Parag Jain (Jira)


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

Parag Jain updated CALCITE-5719:

Description: 
We are using calcite-avatica-go driver to connect to Apache Druid and facing 
few issues -
 # In Go sql package when an idle connection is picked from the pool, 
*ResetSession* method is called on the connection. In the drivers 
implementation of this method 
[here|https://github.com/apache/calcite-avatica-go/blob/main/connection.go#L236],
 *registerConn* method is called which actually does an *OpenConnectionRequest* 
with the existing connectionId. On the Druid side it actually throws an 
exception 
[here|https://github.com/apache/druid/blob/master/sql/src/main/java/org/apache/druid/sql/avatica/DruidMeta.java#L823]
 saying the connection is already open. I checked other driver implementations 
like [postgres|https://github.com/jackc/pgx/blob/master/stdlib/sql.go#L307] and 
[mysql|https://github.com/go-sql-driver/mysql/blob/master/connection.go#L638] 
for ResetSession method and they actually don't open a new connection. So not 
sure about the reason for doing this here. Any thoughts on this ? Example 
exception stack trace -
{code:java}
2023-05-22T19:24:47,357 ERROR [qtp44562-140] 
org.apache.druid.sql.avatica.DruidMeta - Connection 
[fcf73260-cb72-b867-154b-e39a19569c5e] already open.
org.apache.druid.java.util.common.ISE: Connection 
[fcf73260-cb72-b867-154b-e39a19569c5e] already open.
    at 
org.apache.druid.sql.avatica.DruidMeta.openDruidConnection(DruidMeta.java:823) 
~[classes/:?]
    at 
org.apache.druid.sql.avatica.DruidMeta.openConnection(DruidMeta.java:208) 
~[classes/:?]
    at 
org.apache.calcite.avatica.remote.LocalService.apply(LocalService.java:285) 
~[avatica-core-1.17.0.jar:1.17.0]
    at 
org.apache.calcite.avatica.remote.Service$OpenConnectionRequest.accept(Service.java:1770)
 ~[avatica-core-1.17.0.jar:1.17.0]
    at 
org.apache.calcite.avatica.remote.Service$OpenConnectionRequest.accept(Service.java:1750)
 ~[avatica-core-1.17.0.jar:1.17.0]
    at 
org.apache.calcite.avatica.remote.AbstractHandler.apply(AbstractHandler.java:94)
 ~[avatica-core-1.17.0.jar:1.17.0]
    at 
org.apache.calcite.avatica.remote.ProtobufHandler.apply(ProtobufHandler.java:46)
 ~[avatica-core-1.17.0.jar:1.17.0]
    at 
org.apache.calcite.avatica.server.AvaticaProtobufHandler.handle(AvaticaProtobufHandler.java:126)
 ~[avatica-server-1.17.0.jar:1.17.0]
    at 
org.apache.druid.sql.avatica.DruidAvaticaProtobufHandler.handle(DruidAvaticaProtobufHandler.java:61)
 ~[classes/:?] {code}

    2. Username and pwd not being propagated in the JDBC context. Had to add 
the following code in the 
[Connect|https://github.com/apache/calcite-avatica-go/blob/main/driver.go#L64] 
method of driver.go to make it work
{code:java}
    if config.avaticaUser != "" {
        c.Info["user"] = config.avaticaUser
    }
    if config.avaticaPassword != "" {
        c.Info["password"] = config.avaticaPassword
    }  {code}
    3. My colleague (Benjamin) found open statement leak as well, fixed 
[here|[https://github.com/apache/calcite-avatica-go/commit/9c0eba2fbe15b3f877ee276b889cbd39e1a8ce2d].]
 We plan to contribute all back once the issues are fixed.

  was:
I have been using calcite-avatica-go driver to connect to Apache Druid and 
facing few issues -
 # In Go sql package when an idle connection is picked from the pool, 
*ResetSession* method is called on the connection. In the drivers 
implementation of this method 
[here|https://github.com/apache/calcite-avatica-go/blob/main/connection.go#L236],
 *registerConn* method is called which actually does an *OpenConnectionRequest* 
with the existing connectionId. On the Druid side it actually throws an 
exception 
[here|https://github.com/apache/druid/blob/master/sql/src/main/java/org/apache/druid/sql/avatica/DruidMeta.java#L823]
 saying the connection is already open. I checked other driver implementations 
like [postgres|https://github.com/jackc/pgx/blob/master/stdlib/sql.go#L307] and 
[mysql|https://github.com/go-sql-driver/mysql/blob/master/connection.go#L638] 
for ResetSession method and they actually don't open a new connection. So not 
sure about the reason for doing this here. Any thoughts on this ? Example 
exception stack trace -
{code:java}
2023-05-22T19:24:47,357 ERROR [qtp44562-140] 
org.apache.druid.sql.avatica.DruidMeta - Connection 
[fcf73260-cb72-b867-154b-e39a19569c5e] already open.
org.apache.druid.java.util.common.ISE: Connection 
[fcf73260-cb72-b867-154b-e39a19569c5e] already open.
    at 
org.apache.druid.sql.avatica.DruidMeta.openDruidConnection(DruidMeta.java:823) 
~[classes/:?]
    at 
org.apache.druid.sql.avatica.DruidMeta.openConnection(DruidMeta.java:208) 
~[classes/:?]
    at 
org.apache.calcite.avatica.remote.LocalService.apply(LocalService.java:285) 
~[avatica-core-1.17.0.jar:1.17.0]
    at 

[jira] [Updated] (CALCITE-5719) Issues with connection and authentication with Apache Druid

2023-05-22 Thread Parag Jain (Jira)


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

Parag Jain updated CALCITE-5719:

Description: 
I have been using calcite-avatica-go driver to connect to Apache Druid and 
facing few issues -
 # In Go sql package when an idle connection is picked from the pool, 
*ResetSession* method is called on the connection. In the drivers 
implementation of this method 
[here|https://github.com/apache/calcite-avatica-go/blob/main/connection.go#L236],
 *registerConn* method is called which actually does an *OpenConnectionRequest* 
with the existing connectionId. On the Druid side it actually throws an 
exception 
[here|https://github.com/apache/druid/blob/master/sql/src/main/java/org/apache/druid/sql/avatica/DruidMeta.java#L823]
 saying the connection is already open. I checked other driver implementations 
like [postgres|https://github.com/jackc/pgx/blob/master/stdlib/sql.go#L307] and 
[mysql|https://github.com/go-sql-driver/mysql/blob/master/connection.go#L638] 
for ResetSession method and they actually don't open a new connection. So not 
sure about the reason for doing this here. Any thoughts on this ? Example 
exception stack trace -
{code:java}
2023-05-22T19:24:47,357 ERROR [qtp44562-140] 
org.apache.druid.sql.avatica.DruidMeta - Connection 
[fcf73260-cb72-b867-154b-e39a19569c5e] already open.
org.apache.druid.java.util.common.ISE: Connection 
[fcf73260-cb72-b867-154b-e39a19569c5e] already open.
    at 
org.apache.druid.sql.avatica.DruidMeta.openDruidConnection(DruidMeta.java:823) 
~[classes/:?]
    at 
org.apache.druid.sql.avatica.DruidMeta.openConnection(DruidMeta.java:208) 
~[classes/:?]
    at 
org.apache.calcite.avatica.remote.LocalService.apply(LocalService.java:285) 
~[avatica-core-1.17.0.jar:1.17.0]
    at 
org.apache.calcite.avatica.remote.Service$OpenConnectionRequest.accept(Service.java:1770)
 ~[avatica-core-1.17.0.jar:1.17.0]
    at 
org.apache.calcite.avatica.remote.Service$OpenConnectionRequest.accept(Service.java:1750)
 ~[avatica-core-1.17.0.jar:1.17.0]
    at 
org.apache.calcite.avatica.remote.AbstractHandler.apply(AbstractHandler.java:94)
 ~[avatica-core-1.17.0.jar:1.17.0]
    at 
org.apache.calcite.avatica.remote.ProtobufHandler.apply(ProtobufHandler.java:46)
 ~[avatica-core-1.17.0.jar:1.17.0]
    at 
org.apache.calcite.avatica.server.AvaticaProtobufHandler.handle(AvaticaProtobufHandler.java:126)
 ~[avatica-server-1.17.0.jar:1.17.0]
    at 
org.apache.druid.sql.avatica.DruidAvaticaProtobufHandler.handle(DruidAvaticaProtobufHandler.java:61)
 ~[classes/:?] {code}

    2. Username and pwd not being propagated in the JDBC context. Had to add 
the following code in the 
[Connect|https://github.com/apache/calcite-avatica-go/blob/main/driver.go#L64] 
method of driver.go to make it work
{code:java}
    if config.avaticaUser != "" {
        c.Info["user"] = config.avaticaUser
    }
    if config.avaticaPassword != "" {
        c.Info["password"] = config.avaticaPassword
    }  {code}
    3. My colleague (Benjamin) found open statement leak as well, fixed 
[here|[https://github.com/apache/calcite-avatica-go/commit/9c0eba2fbe15b3f877ee276b889cbd39e1a8ce2d].]
 We plan to contribute all back once the issues are fixed.

  was:
I have been using calcite-avatica-go driver to connect to Apache Druid and 
facing few issues -
 # In Go sql package when an idle connection is picked from the pool, 
*ResetSession* method is called on the connection. In the drivers 
implementation of this method 
[here|https://github.com/apache/calcite-avatica-go/blob/main/connection.go#L236],
 *registerConn* method is called which actually does an *OpenConnectionRequest* 
with the existing connectionId. On the Druid side it actually throws an 
exception 
[here|https://github.com/apache/druid/blob/master/sql/src/main/java/org/apache/druid/sql/avatica/DruidMeta.java#L823]
 saying the connection is already open. I checked other driver implementations 
like [postgres|https://github.com/jackc/pgx/blob/master/stdlib/sql.go#L307] and 
[mysql|https://github.com/go-sql-driver/mysql/blob/master/connection.go#L638] 
for ResetSession method and they actually don't open a new connection. So not 
sure about the reason for doing this here. Any thoughts on this ? Example 
exception stack trace -
{code:java}
2023-05-22T19:24:47,357 ERROR [qtp44562-140] 
org.apache.druid.sql.avatica.DruidMeta - Connection 
[fcf73260-cb72-b867-154b-e39a19569c5e] already open.
org.apache.druid.java.util.common.ISE: Connection 
[fcf73260-cb72-b867-154b-e39a19569c5e] already open.
    at 
org.apache.druid.sql.avatica.DruidMeta.openDruidConnection(DruidMeta.java:823) 
~[classes/:?]
    at 
org.apache.druid.sql.avatica.DruidMeta.openConnection(DruidMeta.java:208) 
~[classes/:?]
    at 
org.apache.calcite.avatica.remote.LocalService.apply(LocalService.java:285) 
~[avatica-core-1.17.0.jar:1.17.0]
    at 

[jira] [Updated] (CALCITE-5719) Issues with connection and authentication with Apache Druid

2023-05-22 Thread Parag Jain (Jira)


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

Parag Jain updated CALCITE-5719:

Description: 
I have been using calcite-avatica-go driver to connect to Apache Druid and 
facing few issues -
 # In Go sql package when an idle connection is picked from the pool, 
*ResetSession* method is called on the connection. In the drivers 
implementation of this method 
[here|https://github.com/apache/calcite-avatica-go/blob/main/connection.go#L236],
 *registerConn* method is called which actually does an *OpenConnectionRequest* 
with the existing connectionId. On the Druid side it actually throws an 
exception 
[here|https://github.com/apache/druid/blob/master/sql/src/main/java/org/apache/druid/sql/avatica/DruidMeta.java#L823]
 saying the connection is already open. I checked other driver implementations 
like [postgres|https://github.com/jackc/pgx/blob/master/stdlib/sql.go#L307] and 
[mysql|https://github.com/go-sql-driver/mysql/blob/master/connection.go#L638] 
for ResetSession method and they actually don't open a new connection. So not 
sure about the reason for doing this here. Any thoughts on this ? Example 
exception stack trace -
{code:java}
2023-05-22T19:24:47,357 ERROR [qtp44562-140] 
org.apache.druid.sql.avatica.DruidMeta - Connection 
[fcf73260-cb72-b867-154b-e39a19569c5e] already open.
org.apache.druid.java.util.common.ISE: Connection 
[fcf73260-cb72-b867-154b-e39a19569c5e] already open.
    at 
org.apache.druid.sql.avatica.DruidMeta.openDruidConnection(DruidMeta.java:823) 
~[classes/:?]
    at 
org.apache.druid.sql.avatica.DruidMeta.openConnection(DruidMeta.java:208) 
~[classes/:?]
    at 
org.apache.calcite.avatica.remote.LocalService.apply(LocalService.java:285) 
~[avatica-core-1.17.0.jar:1.17.0]
    at 
org.apache.calcite.avatica.remote.Service$OpenConnectionRequest.accept(Service.java:1770)
 ~[avatica-core-1.17.0.jar:1.17.0]
    at 
org.apache.calcite.avatica.remote.Service$OpenConnectionRequest.accept(Service.java:1750)
 ~[avatica-core-1.17.0.jar:1.17.0]
    at 
org.apache.calcite.avatica.remote.AbstractHandler.apply(AbstractHandler.java:94)
 ~[avatica-core-1.17.0.jar:1.17.0]
    at 
org.apache.calcite.avatica.remote.ProtobufHandler.apply(ProtobufHandler.java:46)
 ~[avatica-core-1.17.0.jar:1.17.0]
    at 
org.apache.calcite.avatica.server.AvaticaProtobufHandler.handle(AvaticaProtobufHandler.java:126)
 ~[avatica-server-1.17.0.jar:1.17.0]
    at 
org.apache.druid.sql.avatica.DruidAvaticaProtobufHandler.handle(DruidAvaticaProtobufHandler.java:61)
 ~[classes/:?] {code}

 # Username and pwd not being propagated in the JDBC context. Had to add the 
following code in the 
[Connect|https://github.com/apache/calcite-avatica-go/blob/main/driver.go#L64] 
method of driver.go to make it work
{code:java}
    if config.avaticaUser != "" {
        c.Info["user"] = config.avaticaUser
    }
    if config.avaticaPassword != "" {
        c.Info["password"] = config.avaticaPassword
    }  {code}

    3. My colleague found open statement leak as well, fixed 
[here|[https://github.com/apache/calcite-avatica-go/commit/9c0eba2fbe15b3f877ee276b889cbd39e1a8ce2d].]
 We plan to contribute all back once the issues are fixed.

  was:
I have been using calcite-avatica-go driver to connect to Apache Druid and 
facing few issues -
 # In Go sql package when an idle connection is picked from the pool, 
*ResetSession* method is called on the connection. In the drivers 
implementation of this method 
[here|https://github.com/apache/calcite-avatica-go/blob/main/connection.go#L236],
 *registerConn* method is called which actually does an *OpenConnectionRequest* 
with the existing connectionId. On the Druid side it actually throws an 
exception 
[here|https://github.com/apache/druid/blob/master/sql/src/main/java/org/apache/druid/sql/avatica/DruidMeta.java#L823]
 saying the connection is already open. I checked other driver implementations 
like [postgres|https://github.com/jackc/pgx/blob/master/stdlib/sql.go#L307] and 
[mysql|https://github.com/go-sql-driver/mysql/blob/master/connection.go#L638] 
for ResetSession method and they actually don't open a new connection. So not 
sure about the reason for doing this here. Any thoughts on this ?
 # Username and pwd not being propagated in the JDBC context. Had to add the 
following code in the 
[Connect|https://github.com/apache/calcite-avatica-go/blob/main/driver.go#L64] 
method of driver.go to make it work

{code:java}
if config.avaticaUser != "" {
        c.Info["user"] = config.avaticaUser
    }
    if config.avaticaPassword != "" {
        c.Info["password"] = config.avaticaPassword
    } {code}


> Issues with connection and authentication with Apache Druid
> ---
>
> Key: CALCITE-5719
> URL: https://issues.apache.org/jira/browse/CALCITE-5719
> Project: Calcite
>  

[jira] [Updated] (CALCITE-5719) Issues with connection and authentication with Apache Druid

2023-05-22 Thread Parag Jain (Jira)


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

Parag Jain updated CALCITE-5719:

Description: 
I have been using calcite-avatica-go driver to connect to Apache Druid and 
facing few issues -
 # In Go sql package when an idle connection is picked from the pool, 
*ResetSession* method is called on the connection. In the drivers 
implementation of this method 
[here|https://github.com/apache/calcite-avatica-go/blob/main/connection.go#L236],
 *registerConn* method is called which actually does an *OpenConnectionRequest* 
with the existing connectionId. On the Druid side it actually throws an 
exception 
[here|https://github.com/apache/druid/blob/master/sql/src/main/java/org/apache/druid/sql/avatica/DruidMeta.java#L823]
 saying the connection is already open. I checked other driver implementations 
like [postgres|https://github.com/jackc/pgx/blob/master/stdlib/sql.go#L307] and 
[mysql|https://github.com/go-sql-driver/mysql/blob/master/connection.go#L638] 
for ResetSession method and they actually don't open a new connection. So not 
sure about the reason for doing this here. Any thoughts on this ?
 # Username and pwd not being propagated in the JDBC context. Had to add the 
following code in the 
[Connect|https://github.com/apache/calcite-avatica-go/blob/main/driver.go#L64] 
method of driver.go to make it work

{code:java}
if config.avaticaUser != "" {
        c.Info["user"] = config.avaticaUser
    }
    if config.avaticaPassword != "" {
        c.Info["password"] = config.avaticaPassword
    } {code}

  was:
I have been using calcite-avatica-go driver to connect to Apache Druid and 
facing few issues -
 # In Go sql package when an idle connection is picked from the pool, 
*ResetSession* method is called on the connection. In the drivers 
implementation of this method 
[here|https://github.com/apache/calcite-avatica-go/blob/main/connection.go#L236],
 *registerConn* method is called which actually does an *OpenConnectionRequest* 
with the existing connectionId. On the Druid side it actually throws an 
exception 
[here|https://github.com/apache/druid/blob/master/sql/src/main/java/org/apache/druid/sql/avatica/DruidMeta.java#L823]
 saying the connection is already open. I checked other driver implementations 
like [postgres|https://github.com/jackc/pgx/blob/master/stdlib/sql.go#L307] and 
[mysql|https://github.com/go-sql-driver/mysql/blob/master/connection.go#L638] 
for ResetSession method and they actually don't open a new connection. So not 
sure about the reason for doing this here. Any thoughts on this ?
 # Username and pwd not being propagated in the JDBC context. Had to add the 
following code in the [Connect| 
https://github.com/apache/calcite-avatica-go/blob/main/driver.go#L64] method of 
driver.go 

{code:java}
if config.avaticaUser != "" {
        c.Info["user"] = config.avaticaUser
    }
    if config.avaticaPassword != "" {
        c.Info["password"] = config.avaticaPassword
    } {code}


> Issues with connection and authentication with Apache Druid
> ---
>
> Key: CALCITE-5719
> URL: https://issues.apache.org/jira/browse/CALCITE-5719
> Project: Calcite
>  Issue Type: Bug
>  Components: avatica-go
>Reporter: Parag Jain
>Assignee: Francis Chuang
>Priority: Major
>  Labels: avatica
>
> I have been using calcite-avatica-go driver to connect to Apache Druid and 
> facing few issues -
>  # In Go sql package when an idle connection is picked from the pool, 
> *ResetSession* method is called on the connection. In the drivers 
> implementation of this method 
> [here|https://github.com/apache/calcite-avatica-go/blob/main/connection.go#L236],
>  *registerConn* method is called which actually does an 
> *OpenConnectionRequest* with the existing connectionId. On the Druid side it 
> actually throws an exception 
> [here|https://github.com/apache/druid/blob/master/sql/src/main/java/org/apache/druid/sql/avatica/DruidMeta.java#L823]
>  saying the connection is already open. I checked other driver 
> implementations like 
> [postgres|https://github.com/jackc/pgx/blob/master/stdlib/sql.go#L307] and 
> [mysql|https://github.com/go-sql-driver/mysql/blob/master/connection.go#L638] 
> for ResetSession method and they actually don't open a new connection. So not 
> sure about the reason for doing this here. Any thoughts on this ?
>  # Username and pwd not being propagated in the JDBC context. Had to add the 
> following code in the 
> [Connect|https://github.com/apache/calcite-avatica-go/blob/main/driver.go#L64]
>  method of driver.go to make it work
> {code:java}
> if config.avaticaUser != "" {
>         c.Info["user"] = config.avaticaUser
>     }
>     if config.avaticaPassword != "" {
>         c.Info["password"] = 

[jira] [Updated] (CALCITE-5719) Issues with connection and authentication with Apache Druid

2023-05-22 Thread Parag Jain (Jira)


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

Parag Jain updated CALCITE-5719:

Summary: Issues with connection and authentication with Apache Druid  (was: 
Possible bug with connection and authentication with Apache Druid)

> Issues with connection and authentication with Apache Druid
> ---
>
> Key: CALCITE-5719
> URL: https://issues.apache.org/jira/browse/CALCITE-5719
> Project: Calcite
>  Issue Type: Bug
>  Components: avatica-go
>Reporter: Parag Jain
>Assignee: Francis Chuang
>Priority: Major
>  Labels: avatica
>
> I have been using calcite-avatica-go driver to connect to Apache Druid and 
> facing few issues -
>  # In Go sql package when an idle connection is picked from the pool, 
> *ResetSession* method is called on the connection. In the drivers 
> implementation of this method 
> [here|https://github.com/apache/calcite-avatica-go/blob/main/connection.go#L236],
>  *registerConn* method is called which actually does an 
> *OpenConnectionRequest* with the existing connectionId. On the Druid side it 
> actually throws an exception 
> [here|https://github.com/apache/druid/blob/master/sql/src/main/java/org/apache/druid/sql/avatica/DruidMeta.java#L823]
>  saying the connection is already open. I checked other driver 
> implementations like 
> [postgres|https://github.com/jackc/pgx/blob/master/stdlib/sql.go#L307] and 
> [mysql|https://github.com/go-sql-driver/mysql/blob/master/connection.go#L638] 
> for ResetSession method and they actually don't open a new connection. So not 
> sure about the reason for doing this here. Any thoughts on this ?
>  # Username and pwd not being propagated in the JDBC context. Had to add the 
> following code in the [Connect| 
> https://github.com/apache/calcite-avatica-go/blob/main/driver.go#L64] method 
> of driver.go 
> {code:java}
> if config.avaticaUser != "" {
>         c.Info["user"] = config.avaticaUser
>     }
>     if config.avaticaPassword != "" {
>         c.Info["password"] = config.avaticaPassword
>     } {code}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Created] (CALCITE-5719) Possible bug with connection and authentication with Apache Druid

2023-05-22 Thread Parag Jain (Jira)
Parag Jain created CALCITE-5719:
---

 Summary: Possible bug with connection and authentication with 
Apache Druid
 Key: CALCITE-5719
 URL: https://issues.apache.org/jira/browse/CALCITE-5719
 Project: Calcite
  Issue Type: Bug
  Components: avatica-go
Reporter: Parag Jain
Assignee: Francis Chuang


I have been using calcite-avatica-go driver to connect to Apache Druid and 
facing few issues -
 # In Go sql package when an idle connection is picked from the pool, 
*ResetSession* method is called on the connection. In the drivers 
implementation of this method 
[here|https://github.com/apache/calcite-avatica-go/blob/main/connection.go#L236],
 *registerConn* method is called which actually does an *OpenConnectionRequest* 
with the existing connectionId. On the Druid side it actually throws an 
exception 
[here|https://github.com/apache/druid/blob/master/sql/src/main/java/org/apache/druid/sql/avatica/DruidMeta.java#L823]
 saying the connection is already open. I checked other driver implementations 
like [postgres|https://github.com/jackc/pgx/blob/master/stdlib/sql.go#L307] and 
[mysql|https://github.com/go-sql-driver/mysql/blob/master/connection.go#L638] 
for ResetSession method and they actually don't open a new connection. So not 
sure about the reason for doing this here. Any thoughts on this ?
 # Username and pwd not being propagated in the JDBC context. Had to add the 
following code in the [Connect| 
https://github.com/apache/calcite-avatica-go/blob/main/driver.go#L64] method of 
driver.go 

{code:java}
if config.avaticaUser != "" {
        c.Info["user"] = config.avaticaUser
    }
    if config.avaticaPassword != "" {
        c.Info["password"] = config.avaticaPassword
    } {code}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Commented] (CALCITE-5271) Error while unparsing FLOOR function using Postgres dialect

2022-09-27 Thread Parag Jain (Jira)


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

Parag Jain commented on CALCITE-5271:
-

It passes because the dialect is not used at all while getting the string
sql, see here
,
null is passed in the dialect parameter while calling the toSqlString
method. Just wanted to point it out.




> Error while unparsing FLOOR function using Postgres dialect
> ---
>
> Key: CALCITE-5271
> URL: https://issues.apache.org/jira/browse/CALCITE-5271
> Project: Calcite
>  Issue Type: Bug
>Reporter: Parag Jain
>Assignee: Mou Wu
>Priority: Minor
>
> Using Calcite(1.30.0) to parse this query - select FLOOR(TIMESTAMP 
> '2022-08-01' TO Year)
> Parsing is successful but while doing 
> `toSqlString(PostgresqlSqlDialect.DEFAULT).getSql()`. on the parsed *SqlNode* 
> getting following exception -
>  
> {code:java}
> Request failed: java.lang.ClassCastException: class 
> org.apache.calcite.sql.SqlIntervalQualifier cannot be cast to class 
> org.apache.calcite.sql.SqlLiteral 
> at 
> org.apache.calcite.sql.dialect.PostgresqlSqlDialect.unparseCall(PostgresqlSqlDialect.java:128)
> at org.apache.calcite.sql.SqlCall.unparse(SqlCall.java:126)
> at 
> org.apache.calcite.sql.pretty.SqlPrettyWriter$FrameImpl.list2(SqlPrettyWriter.java:1303)
> at 
> org.apache.calcite.sql.pretty.SqlPrettyWriter$FrameImpl.list(SqlPrettyWriter.java:1283)
> at 
> org.apache.calcite.sql.pretty.SqlPrettyWriter.list(SqlPrettyWriter.java:1080)
> at 
> org.apache.calcite.sql.SqlSelectOperator.unparse(SqlSelectOperator.java:154)
> at org.apache.calcite.sql.SqlDialect.unparseCall(SqlDialect.java:460)
> at 
> org.apache.calcite.sql.dialect.PostgresqlSqlDialect.unparseCall(PostgresqlSqlDialect.java:137)
> at org.apache.calcite.sql.SqlSelect.unparse(SqlSelect.java:261)
> at org.apache.calcite.sql.SqlNode.toSqlString(SqlNode.java:156)
> at org.apache.calcite.sql.SqlNode.toSqlString(SqlNode.java:178)
> at org.apache.calcite.sql.SqlNode.toSqlString(SqlNode.java:187){code}
> Looks like a bug as the "Year" token gets parsed to SqlIntervalQualifier but 
> expectation is of SqlLiteral. Here's a 
> [PR|https://github.com/apache/calcite/pull/2897] with test case to reproduce 
> the issue.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Commented] (CALCITE-5271) Error while unparsing FLOOR function using Postgres dialect

2022-09-27 Thread Parag Jain (Jira)


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

Parag Jain commented on CALCITE-5271:
-

ok added a test

in SqlParserTest file and it fails.




> Error while unparsing FLOOR function using Postgres dialect
> ---
>
> Key: CALCITE-5271
> URL: https://issues.apache.org/jira/browse/CALCITE-5271
> Project: Calcite
>  Issue Type: Bug
>Reporter: Parag Jain
>Assignee: Mou Wu
>Priority: Minor
>
> Using Calcite(1.30.0) to parse this query - select FLOOR(TIMESTAMP 
> '2022-08-01' TO Year)
> Parsing is successful but while doing 
> `toSqlString(PostgresqlSqlDialect.DEFAULT).getSql()`. on the parsed *SqlNode* 
> getting following exception -
>  
> {code:java}
> Request failed: java.lang.ClassCastException: class 
> org.apache.calcite.sql.SqlIntervalQualifier cannot be cast to class 
> org.apache.calcite.sql.SqlLiteral 
> at 
> org.apache.calcite.sql.dialect.PostgresqlSqlDialect.unparseCall(PostgresqlSqlDialect.java:128)
> at org.apache.calcite.sql.SqlCall.unparse(SqlCall.java:126)
> at 
> org.apache.calcite.sql.pretty.SqlPrettyWriter$FrameImpl.list2(SqlPrettyWriter.java:1303)
> at 
> org.apache.calcite.sql.pretty.SqlPrettyWriter$FrameImpl.list(SqlPrettyWriter.java:1283)
> at 
> org.apache.calcite.sql.pretty.SqlPrettyWriter.list(SqlPrettyWriter.java:1080)
> at 
> org.apache.calcite.sql.SqlSelectOperator.unparse(SqlSelectOperator.java:154)
> at org.apache.calcite.sql.SqlDialect.unparseCall(SqlDialect.java:460)
> at 
> org.apache.calcite.sql.dialect.PostgresqlSqlDialect.unparseCall(PostgresqlSqlDialect.java:137)
> at org.apache.calcite.sql.SqlSelect.unparse(SqlSelect.java:261)
> at org.apache.calcite.sql.SqlNode.toSqlString(SqlNode.java:156)
> at org.apache.calcite.sql.SqlNode.toSqlString(SqlNode.java:178)
> at org.apache.calcite.sql.SqlNode.toSqlString(SqlNode.java:187){code}
> Looks like a bug as the "Year" token gets parsed to SqlIntervalQualifier but 
> expectation is of SqlLiteral. Here's a 
> [PR|https://github.com/apache/calcite/pull/2897] with test case to reproduce 
> the issue.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Commented] (CALCITE-5271) Error while unparsing FLOOR function using Postgres dialect

2022-09-27 Thread Parag Jain (Jira)


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

Parag Jain commented on CALCITE-5271:
-

What is I just want to convert parsed SqlNode to a string representation,
for that I will use toString and that will use unparse and fail. Is this
not valid ? Am I doing something wrong?




> Error while unparsing FLOOR function using Postgres dialect
> ---
>
> Key: CALCITE-5271
> URL: https://issues.apache.org/jira/browse/CALCITE-5271
> Project: Calcite
>  Issue Type: Bug
>Reporter: Parag Jain
>Assignee: Mou Wu
>Priority: Minor
>
> Using Calcite(1.30.0) to parse this query - select FLOOR(TIMESTAMP 
> '2022-08-01' TO Year)
> Parsing is successful but while doing 
> `toSqlString(PostgresqlSqlDialect.DEFAULT).getSql()`. on the parsed *SqlNode* 
> getting following exception -
>  
> {code:java}
> Request failed: java.lang.ClassCastException: class 
> org.apache.calcite.sql.SqlIntervalQualifier cannot be cast to class 
> org.apache.calcite.sql.SqlLiteral 
> at 
> org.apache.calcite.sql.dialect.PostgresqlSqlDialect.unparseCall(PostgresqlSqlDialect.java:128)
> at org.apache.calcite.sql.SqlCall.unparse(SqlCall.java:126)
> at 
> org.apache.calcite.sql.pretty.SqlPrettyWriter$FrameImpl.list2(SqlPrettyWriter.java:1303)
> at 
> org.apache.calcite.sql.pretty.SqlPrettyWriter$FrameImpl.list(SqlPrettyWriter.java:1283)
> at 
> org.apache.calcite.sql.pretty.SqlPrettyWriter.list(SqlPrettyWriter.java:1080)
> at 
> org.apache.calcite.sql.SqlSelectOperator.unparse(SqlSelectOperator.java:154)
> at org.apache.calcite.sql.SqlDialect.unparseCall(SqlDialect.java:460)
> at 
> org.apache.calcite.sql.dialect.PostgresqlSqlDialect.unparseCall(PostgresqlSqlDialect.java:137)
> at org.apache.calcite.sql.SqlSelect.unparse(SqlSelect.java:261)
> at org.apache.calcite.sql.SqlNode.toSqlString(SqlNode.java:156)
> at org.apache.calcite.sql.SqlNode.toSqlString(SqlNode.java:178)
> at org.apache.calcite.sql.SqlNode.toSqlString(SqlNode.java:187){code}
> Looks like a bug as the "Year" token gets parsed to SqlIntervalQualifier but 
> expectation is of SqlLiteral. Here's a 
> [PR|https://github.com/apache/calcite/pull/2897] with test case to reproduce 
> the issue.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Commented] (CALCITE-5271) Error while unparsing FLOOR function using Postgres dialect

2022-09-20 Thread Parag Jain (Jira)


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

Parag Jain commented on CALCITE-5271:
-

I agree with this fix and this seems to be the correct behaviour to me.

> Error while unparsing FLOOR function using Postgres dialect
> ---
>
> Key: CALCITE-5271
> URL: https://issues.apache.org/jira/browse/CALCITE-5271
> Project: Calcite
>  Issue Type: Bug
>Reporter: Parag Jain
>Assignee: Mou Wu
>Priority: Minor
>
> Using Calcite(1.30.0) to parse this query - select FLOOR(TIMESTAMP 
> '2022-08-01' TO Year)
> Parsing is successful but while doing 
> `toSqlString(PostgresqlSqlDialect.DEFAULT).getSql()`. on the parsed *SqlNode* 
> getting following exception -
>  
> {code:java}
> Request failed: java.lang.ClassCastException: class 
> org.apache.calcite.sql.SqlIntervalQualifier cannot be cast to class 
> org.apache.calcite.sql.SqlLiteral 
> at 
> org.apache.calcite.sql.dialect.PostgresqlSqlDialect.unparseCall(PostgresqlSqlDialect.java:128)
> at org.apache.calcite.sql.SqlCall.unparse(SqlCall.java:126)
> at 
> org.apache.calcite.sql.pretty.SqlPrettyWriter$FrameImpl.list2(SqlPrettyWriter.java:1303)
> at 
> org.apache.calcite.sql.pretty.SqlPrettyWriter$FrameImpl.list(SqlPrettyWriter.java:1283)
> at 
> org.apache.calcite.sql.pretty.SqlPrettyWriter.list(SqlPrettyWriter.java:1080)
> at 
> org.apache.calcite.sql.SqlSelectOperator.unparse(SqlSelectOperator.java:154)
> at org.apache.calcite.sql.SqlDialect.unparseCall(SqlDialect.java:460)
> at 
> org.apache.calcite.sql.dialect.PostgresqlSqlDialect.unparseCall(PostgresqlSqlDialect.java:137)
> at org.apache.calcite.sql.SqlSelect.unparse(SqlSelect.java:261)
> at org.apache.calcite.sql.SqlNode.toSqlString(SqlNode.java:156)
> at org.apache.calcite.sql.SqlNode.toSqlString(SqlNode.java:178)
> at org.apache.calcite.sql.SqlNode.toSqlString(SqlNode.java:187){code}
> Looks like a bug as the "Year" token gets parsed to SqlIntervalQualifier but 
> expectation is of SqlLiteral. Here's a 
> [PR|https://github.com/apache/calcite/pull/2897] with test case to reproduce 
> the issue.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Comment Edited] (CALCITE-5271) Error while unparsing FLOOR function using Postgres dialect

2022-09-20 Thread Parag Jain (Jira)


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

Parag Jain edited comment on CALCITE-5271 at 9/20/22 4:26 PM:
--

Sorry for the confusion. I am not suggesting to remove the FLOOR function. I 
was suggesting removing the support for FLOOR(Timestamp to TIMEUNIT) syntax in 
PostgresSqlDialect since as per my knowledge even standard sql does not support 
FLOOR(Timestamp to TIMEUNIT) operator.
 
But now I think more about it, you mentioned Calcite extends standard SQL to 
support this and even users may convert from some dialect which supports this 
syntax to Postgres in which case this conversion will be super useful. So I was 
wrong in suggesting this.


was (Author: pjain1):
Sorry for the confusion. I am not suggesting to remove the FLOOR function. I 
was suggesting removing the support for FLOOR(Timestamp to TIMEUNIT) syntax in 
PostgresSqlDialect since as per my knowledge even standard sql does not support 
FLOOR(Timestamp to TIMEUNIT) operator.
 
But now I think more about it, you mentioned Calcite extends standard SQL to 
support this and even users may convert from some dialect which supports this 
syntax to Postgres in which case this conversion will be super useful.

> Error while unparsing FLOOR function using Postgres dialect
> ---
>
> Key: CALCITE-5271
> URL: https://issues.apache.org/jira/browse/CALCITE-5271
> Project: Calcite
>  Issue Type: Bug
>Reporter: Parag Jain
>Assignee: Mou Wu
>Priority: Minor
>
> Using Calcite(1.30.0) to parse this query - select FLOOR(TIMESTAMP 
> '2022-08-01' TO Year)
> Parsing is successful but while doing 
> `toSqlString(PostgresqlSqlDialect.DEFAULT).getSql()`. on the parsed *SqlNode* 
> getting following exception -
>  
> {code:java}
> Request failed: java.lang.ClassCastException: class 
> org.apache.calcite.sql.SqlIntervalQualifier cannot be cast to class 
> org.apache.calcite.sql.SqlLiteral 
> at 
> org.apache.calcite.sql.dialect.PostgresqlSqlDialect.unparseCall(PostgresqlSqlDialect.java:128)
> at org.apache.calcite.sql.SqlCall.unparse(SqlCall.java:126)
> at 
> org.apache.calcite.sql.pretty.SqlPrettyWriter$FrameImpl.list2(SqlPrettyWriter.java:1303)
> at 
> org.apache.calcite.sql.pretty.SqlPrettyWriter$FrameImpl.list(SqlPrettyWriter.java:1283)
> at 
> org.apache.calcite.sql.pretty.SqlPrettyWriter.list(SqlPrettyWriter.java:1080)
> at 
> org.apache.calcite.sql.SqlSelectOperator.unparse(SqlSelectOperator.java:154)
> at org.apache.calcite.sql.SqlDialect.unparseCall(SqlDialect.java:460)
> at 
> org.apache.calcite.sql.dialect.PostgresqlSqlDialect.unparseCall(PostgresqlSqlDialect.java:137)
> at org.apache.calcite.sql.SqlSelect.unparse(SqlSelect.java:261)
> at org.apache.calcite.sql.SqlNode.toSqlString(SqlNode.java:156)
> at org.apache.calcite.sql.SqlNode.toSqlString(SqlNode.java:178)
> at org.apache.calcite.sql.SqlNode.toSqlString(SqlNode.java:187){code}
> Looks like a bug as the "Year" token gets parsed to SqlIntervalQualifier but 
> expectation is of SqlLiteral. Here's a 
> [PR|https://github.com/apache/calcite/pull/2897] with test case to reproduce 
> the issue.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Commented] (CALCITE-5271) Error while unparsing FLOOR function using Postgres dialect

2022-09-20 Thread Parag Jain (Jira)


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

Parag Jain commented on CALCITE-5271:
-

Sorry for the confusion. I am not suggesting to remove the FLOOR function. I 
was suggesting removing the support for FLOOR(Timestamp to TIMEUNIT) syntax in 
PostgresSqlDialect since as per my knowledge even standard sql does not support 
FLOOR(Timestamp to TIMEUNIT) operator.
 
But now I think more about it, you mentioned Calcite extends standard SQL to 
support this and even users may convert from some dialect which supports this 
syntax to Postgres in which case this conversion will be super useful.

> Error while unparsing FLOOR function using Postgres dialect
> ---
>
> Key: CALCITE-5271
> URL: https://issues.apache.org/jira/browse/CALCITE-5271
> Project: Calcite
>  Issue Type: Bug
>Reporter: Parag Jain
>Assignee: Mou Wu
>Priority: Minor
>
> Using Calcite(1.30.0) to parse this query - select FLOOR(TIMESTAMP 
> '2022-08-01' TO Year)
> Parsing is successful but while doing 
> `toSqlString(PostgresqlSqlDialect.DEFAULT).getSql()`. on the parsed *SqlNode* 
> getting following exception -
>  
> {code:java}
> Request failed: java.lang.ClassCastException: class 
> org.apache.calcite.sql.SqlIntervalQualifier cannot be cast to class 
> org.apache.calcite.sql.SqlLiteral 
> at 
> org.apache.calcite.sql.dialect.PostgresqlSqlDialect.unparseCall(PostgresqlSqlDialect.java:128)
> at org.apache.calcite.sql.SqlCall.unparse(SqlCall.java:126)
> at 
> org.apache.calcite.sql.pretty.SqlPrettyWriter$FrameImpl.list2(SqlPrettyWriter.java:1303)
> at 
> org.apache.calcite.sql.pretty.SqlPrettyWriter$FrameImpl.list(SqlPrettyWriter.java:1283)
> at 
> org.apache.calcite.sql.pretty.SqlPrettyWriter.list(SqlPrettyWriter.java:1080)
> at 
> org.apache.calcite.sql.SqlSelectOperator.unparse(SqlSelectOperator.java:154)
> at org.apache.calcite.sql.SqlDialect.unparseCall(SqlDialect.java:460)
> at 
> org.apache.calcite.sql.dialect.PostgresqlSqlDialect.unparseCall(PostgresqlSqlDialect.java:137)
> at org.apache.calcite.sql.SqlSelect.unparse(SqlSelect.java:261)
> at org.apache.calcite.sql.SqlNode.toSqlString(SqlNode.java:156)
> at org.apache.calcite.sql.SqlNode.toSqlString(SqlNode.java:178)
> at org.apache.calcite.sql.SqlNode.toSqlString(SqlNode.java:187){code}
> Looks like a bug as the "Year" token gets parsed to SqlIntervalQualifier but 
> expectation is of SqlLiteral. Here's a 
> [PR|https://github.com/apache/calcite/pull/2897] with test case to reproduce 
> the issue.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Commented] (CALCITE-5271) Error while unparsing FLOOR function using Postgres dialect

2022-09-20 Thread Parag Jain (Jira)


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

Parag Jain commented on CALCITE-5271:
-

My understanding is  Floor(Timestamp to TIMEUNIT) is not supported by
postgres natively but then why is Calcite handling this syntax in unparse
call, so either this should be removed or supported fully.




> Error while unparsing FLOOR function using Postgres dialect
> ---
>
> Key: CALCITE-5271
> URL: https://issues.apache.org/jira/browse/CALCITE-5271
> Project: Calcite
>  Issue Type: Bug
>Reporter: Parag Jain
>Assignee: Mou Wu
>Priority: Minor
>
> Using Calcite(1.30.0) to parse this query - select FLOOR(TIMESTAMP 
> '2022-08-01' TO Year)
> Parsing is successful but while doing 
> `toSqlString(PostgresqlSqlDialect.DEFAULT).getSql()`. on the parsed *SqlNode* 
> getting following exception -
>  
> {code:java}
> Request failed: java.lang.ClassCastException: class 
> org.apache.calcite.sql.SqlIntervalQualifier cannot be cast to class 
> org.apache.calcite.sql.SqlLiteral 
> at 
> org.apache.calcite.sql.dialect.PostgresqlSqlDialect.unparseCall(PostgresqlSqlDialect.java:128)
> at org.apache.calcite.sql.SqlCall.unparse(SqlCall.java:126)
> at 
> org.apache.calcite.sql.pretty.SqlPrettyWriter$FrameImpl.list2(SqlPrettyWriter.java:1303)
> at 
> org.apache.calcite.sql.pretty.SqlPrettyWriter$FrameImpl.list(SqlPrettyWriter.java:1283)
> at 
> org.apache.calcite.sql.pretty.SqlPrettyWriter.list(SqlPrettyWriter.java:1080)
> at 
> org.apache.calcite.sql.SqlSelectOperator.unparse(SqlSelectOperator.java:154)
> at org.apache.calcite.sql.SqlDialect.unparseCall(SqlDialect.java:460)
> at 
> org.apache.calcite.sql.dialect.PostgresqlSqlDialect.unparseCall(PostgresqlSqlDialect.java:137)
> at org.apache.calcite.sql.SqlSelect.unparse(SqlSelect.java:261)
> at org.apache.calcite.sql.SqlNode.toSqlString(SqlNode.java:156)
> at org.apache.calcite.sql.SqlNode.toSqlString(SqlNode.java:178)
> at org.apache.calcite.sql.SqlNode.toSqlString(SqlNode.java:187){code}
> Looks like a bug as the "Year" token gets parsed to SqlIntervalQualifier but 
> expectation is of SqlLiteral. Here's a 
> [PR|https://github.com/apache/calcite/pull/2897] with test case to reproduce 
> the issue.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Commented] (CALCITE-5271) Error while unparsing FLOOR function using Postgres dialect

2022-09-07 Thread Parag Jain (Jira)


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

Parag Jain commented on CALCITE-5271:
-

I think you are right, postgres does not support Floor with timestamp and
supports only date_trunc. My bad here, I guess I got confused by the
unparseCall method in PostgresqlSqlDialect method here

and
the fact that duckdb is postgres dialect compatible and Floor(Timestamp to
TIMEUNIT) is supported by it. I am using calcite lib in front of duckdb.

But in any case since the PostgresqlSqlDialect unparseCall method is
specifically handling this syntax, shouldn't the unparsing of this call
just work ?




> Error while unparsing FLOOR function using Postgres dialect
> ---
>
> Key: CALCITE-5271
> URL: https://issues.apache.org/jira/browse/CALCITE-5271
> Project: Calcite
>  Issue Type: Bug
>Reporter: Parag Jain
>Assignee: Mou Wu
>Priority: Minor
>
> Using Calcite(1.30.0) to parse this query - select FLOOR(TIMESTAMP 
> '2022-08-01' TO Year)
> Parsing is successful but while doing 
> `toSqlString(PostgresqlSqlDialect.DEFAULT).getSql()`. on the parsed *SqlNode* 
> getting following exception -
>  
> {code:java}
> Request failed: java.lang.ClassCastException: class 
> org.apache.calcite.sql.SqlIntervalQualifier cannot be cast to class 
> org.apache.calcite.sql.SqlLiteral 
> at 
> org.apache.calcite.sql.dialect.PostgresqlSqlDialect.unparseCall(PostgresqlSqlDialect.java:128)
> at org.apache.calcite.sql.SqlCall.unparse(SqlCall.java:126)
> at 
> org.apache.calcite.sql.pretty.SqlPrettyWriter$FrameImpl.list2(SqlPrettyWriter.java:1303)
> at 
> org.apache.calcite.sql.pretty.SqlPrettyWriter$FrameImpl.list(SqlPrettyWriter.java:1283)
> at 
> org.apache.calcite.sql.pretty.SqlPrettyWriter.list(SqlPrettyWriter.java:1080)
> at 
> org.apache.calcite.sql.SqlSelectOperator.unparse(SqlSelectOperator.java:154)
> at org.apache.calcite.sql.SqlDialect.unparseCall(SqlDialect.java:460)
> at 
> org.apache.calcite.sql.dialect.PostgresqlSqlDialect.unparseCall(PostgresqlSqlDialect.java:137)
> at org.apache.calcite.sql.SqlSelect.unparse(SqlSelect.java:261)
> at org.apache.calcite.sql.SqlNode.toSqlString(SqlNode.java:156)
> at org.apache.calcite.sql.SqlNode.toSqlString(SqlNode.java:178)
> at org.apache.calcite.sql.SqlNode.toSqlString(SqlNode.java:187){code}
> Looks like a bug as the "Year" token gets parsed to SqlIntervalQualifier but 
> expectation is of SqlLiteral. Here's a 
> [PR|https://github.com/apache/calcite/pull/2897] with test case to reproduce 
> the issue.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Commented] (CALCITE-5271) Error while unparsing FLOOR function using Postgres dialect

2022-09-07 Thread Parag Jain (Jira)


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

Parag Jain commented on CALCITE-5271:
-

Thanks please go ahead with the fix. I am not sure how to appropriately fix
it as I am not much familiar with it yet.




> Error while unparsing FLOOR function using Postgres dialect
> ---
>
> Key: CALCITE-5271
> URL: https://issues.apache.org/jira/browse/CALCITE-5271
> Project: Calcite
>  Issue Type: Bug
>Reporter: Parag Jain
>Priority: Minor
>
> Using Calcite(1.30.0) to parse this query - select FLOOR(TIMESTAMP 
> '2022-08-01' TO Year)
> Parsing is successful but while doing 
> `toSqlString(PostgresqlSqlDialect.DEFAULT).getSql()`. on the parsed *SqlNode* 
> getting following exception -
>  
> {code:java}
> Request failed: java.lang.ClassCastException: class 
> org.apache.calcite.sql.SqlIntervalQualifier cannot be cast to class 
> org.apache.calcite.sql.SqlLiteral 
> at 
> org.apache.calcite.sql.dialect.PostgresqlSqlDialect.unparseCall(PostgresqlSqlDialect.java:128)
> at org.apache.calcite.sql.SqlCall.unparse(SqlCall.java:126)
> at 
> org.apache.calcite.sql.pretty.SqlPrettyWriter$FrameImpl.list2(SqlPrettyWriter.java:1303)
> at 
> org.apache.calcite.sql.pretty.SqlPrettyWriter$FrameImpl.list(SqlPrettyWriter.java:1283)
> at 
> org.apache.calcite.sql.pretty.SqlPrettyWriter.list(SqlPrettyWriter.java:1080)
> at 
> org.apache.calcite.sql.SqlSelectOperator.unparse(SqlSelectOperator.java:154)
> at org.apache.calcite.sql.SqlDialect.unparseCall(SqlDialect.java:460)
> at 
> org.apache.calcite.sql.dialect.PostgresqlSqlDialect.unparseCall(PostgresqlSqlDialect.java:137)
> at org.apache.calcite.sql.SqlSelect.unparse(SqlSelect.java:261)
> at org.apache.calcite.sql.SqlNode.toSqlString(SqlNode.java:156)
> at org.apache.calcite.sql.SqlNode.toSqlString(SqlNode.java:178)
> at org.apache.calcite.sql.SqlNode.toSqlString(SqlNode.java:187){code}
> Looks like a bug as the "Year" token gets parsed to SqlIntervalQualifier but 
> expectation is of SqlLiteral. Here's a 
> [PR|https://github.com/apache/calcite/pull/2897] with test case to reproduce 
> the issue.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Created] (CALCITE-5271) Error while unparsing FLOOR function using Postgres dialect

2022-09-07 Thread Parag Jain (Jira)
Parag Jain created CALCITE-5271:
---

 Summary: Error while unparsing FLOOR function using Postgres 
dialect
 Key: CALCITE-5271
 URL: https://issues.apache.org/jira/browse/CALCITE-5271
 Project: Calcite
  Issue Type: Bug
Reporter: Parag Jain


Using Calcite(1.30.0) to parse this query - select FLOOR(TIMESTAMP '2022-08-01' 
TO Year)

Parsing is successful but while doing 
`toSqlString(PostgresqlSqlDialect.DEFAULT).getSql()`. on the parsed *SqlNode* 
getting following exception -
 
{code:java}
Request failed: java.lang.ClassCastException: class 
org.apache.calcite.sql.SqlIntervalQualifier cannot be cast to class 
org.apache.calcite.sql.SqlLiteral 
at 
org.apache.calcite.sql.dialect.PostgresqlSqlDialect.unparseCall(PostgresqlSqlDialect.java:128)
at org.apache.calcite.sql.SqlCall.unparse(SqlCall.java:126)
at 
org.apache.calcite.sql.pretty.SqlPrettyWriter$FrameImpl.list2(SqlPrettyWriter.java:1303)
at 
org.apache.calcite.sql.pretty.SqlPrettyWriter$FrameImpl.list(SqlPrettyWriter.java:1283)
at org.apache.calcite.sql.pretty.SqlPrettyWriter.list(SqlPrettyWriter.java:1080)
at org.apache.calcite.sql.SqlSelectOperator.unparse(SqlSelectOperator.java:154)
at org.apache.calcite.sql.SqlDialect.unparseCall(SqlDialect.java:460)
at 
org.apache.calcite.sql.dialect.PostgresqlSqlDialect.unparseCall(PostgresqlSqlDialect.java:137)
at org.apache.calcite.sql.SqlSelect.unparse(SqlSelect.java:261)
at org.apache.calcite.sql.SqlNode.toSqlString(SqlNode.java:156)
at org.apache.calcite.sql.SqlNode.toSqlString(SqlNode.java:178)
at org.apache.calcite.sql.SqlNode.toSqlString(SqlNode.java:187){code}

Looks like a bug as the "Year" token gets parsed to SqlIntervalQualifier but 
expectation is of SqlLiteral. Here's a 
[PR|https://github.com/apache/calcite/pull/2897] with test case to reproduce 
the issue.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Created] (CALCITE-5219) Serializing parsed SqlNode/AST

2022-07-26 Thread Parag Jain (Jira)
Parag Jain created CALCITE-5219:
---

 Summary: Serializing parsed SqlNode/AST
 Key: CALCITE-5219
 URL: https://issues.apache.org/jira/browse/CALCITE-5219
 Project: Calcite
  Issue Type: Wish
  Components: core
Reporter: Parag Jain


It would be a good feature for calcite to be able to serialize the parsed 
SqlNode with type information so that it can be passed to different systems 
over wire for query intelligence. 



--
This message was sent by Atlassian Jira
(v8.20.10#820010)