[jira] [Commented] (CALCITE-2219) Avatica Connection/Statement/ResultSet don't throw if resource is closed

2018-03-21 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on CALCITE-2219:
-

Github user joshelser commented on the issue:

https://github.com/apache/calcite-avatica/pull/33
  
> Not really triggered by a bug, but more by the extra code in Drill and 
Dremio JDBC drivers to implements the JDBC spec. Let me see if can reuse the 
same strategy as the Drill code (helper class to iterate over methods and check 
that the methods throws the correct exception).

Ok. I definitely didn't want to suggest that you try to cover every single 
one of these methods you fixed up :). I like to see at least one test added 
when we fix straighforward bugs like this, even if it is known that we're only 
catching one case. Appreciate you looking into it!


> Avatica Connection/Statement/ResultSet don't throw if resource is closed
> 
>
> Key: CALCITE-2219
> URL: https://issues.apache.org/jira/browse/CALCITE-2219
> Project: Calcite
>  Issue Type: Bug
>  Components: avatica
>Reporter: Laurent Goujon
>Assignee: Laurent Goujon
>Priority: Major
>
> According to JDBC spec/Javadoc, almost all methods of 
> {{Connection}}/{{Statement}}/{{PreparedStatement}}/{{ResultSet}} should throw 
> an exception if resource is closed.



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


[jira] [Commented] (CALCITE-2219) Avatica Connection/Statement/ResultSet don't throw if resource is closed

2018-03-21 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on CALCITE-2219:
-

Github user laurentgo commented on the issue:

https://github.com/apache/calcite-avatica/pull/33
  
Not really triggered by a bug, but more by the extra code in Drill and 
Dremio JDBC drivers to implements the JDBC spec. Let me see if can reuse the 
same strategy as the Drill code (helper class to iterate over methods and check 
that the methods throws the correct exception).

There are also lots of methods where unsupported is thrown instead of a 
sqlexception for closed. I wonder if the correct thing to do would be to check 
first for closed, and then throw unsupported, and if it's fine for now.


> Avatica Connection/Statement/ResultSet don't throw if resource is closed
> 
>
> Key: CALCITE-2219
> URL: https://issues.apache.org/jira/browse/CALCITE-2219
> Project: Calcite
>  Issue Type: Bug
>  Components: avatica
>Reporter: Laurent Goujon
>Assignee: Laurent Goujon
>Priority: Major
>
> According to JDBC spec/Javadoc, almost all methods of 
> {{Connection}}/{{Statement}}/{{PreparedStatement}}/{{ResultSet}} should throw 
> an exception if resource is closed.



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


[jira] [Commented] (CALCITE-2059) Apache Geode adapter

2018-03-21 Thread vaquar khan (JIRA)

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

vaquar khan commented on CALCITE-2059:
--

Thanks Christian for quick and humble response .

> Apache Geode adapter
> 
>
> Key: CALCITE-2059
> URL: https://issues.apache.org/jira/browse/CALCITE-2059
> Project: Calcite
>  Issue Type: New Feature
>  Components: geode
>Reporter: Christian Tzolov
>Assignee: Julian Hyde
>Priority: Major
> Fix For: 1.16.0
>
>
> I've been working on a Calcite adapter for [Apache 
> Geode|http://geode.apache.org]. 
> Current implementation uses the plain Geode API and 
> [OQL|http://geode.apache.org/docs/guide/13/developing/querying_basics/chapter_overview.html](Object
>  Query Interface) to push down relational expressions such as projections, 
> filtering, sorting, and grouping . 
> Provided functionality can hopefully address certain Geode use cases and will 
> provide a stepping stone for future improvements. 
> Here are some remaining tasks as i see it:
> * New tests for test suite (and update calcite-test-dataset to support Geode)
> * Add Integration tests that use calcite-test-dataset
> * Documentation



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


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

2018-03-21 Thread Julian Hyde (JIRA)

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

Julian Hyde commented on CALCITE-2211:
--

My understanding for MySQL (I don't know about Vertica etc.) is that 
"bigint(11)" means "BIGINT with a suggested maximum display width of 11". It 
can hold exactly the same values as, say, a bigint(6). For our purposes it is 
BIGINT.

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



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


[jira] [Commented] (CALCITE-2059) Apache Geode adapter

2018-03-21 Thread Julian Hyde (JIRA)

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

Julian Hyde commented on CALCITE-2059:
--

If you want an answer you need to be patient and respectful of people's time. 
No one is getting paid to answer your questions.

> Apache Geode adapter
> 
>
> Key: CALCITE-2059
> URL: https://issues.apache.org/jira/browse/CALCITE-2059
> Project: Calcite
>  Issue Type: New Feature
>  Components: geode
>Reporter: Christian Tzolov
>Assignee: Julian Hyde
>Priority: Major
> Fix For: 1.16.0
>
>
> I've been working on a Calcite adapter for [Apache 
> Geode|http://geode.apache.org]. 
> Current implementation uses the plain Geode API and 
> [OQL|http://geode.apache.org/docs/guide/13/developing/querying_basics/chapter_overview.html](Object
>  Query Interface) to push down relational expressions such as projections, 
> filtering, sorting, and grouping . 
> Provided functionality can hopefully address certain Geode use cases and will 
> provide a stepping stone for future improvements. 
> Here are some remaining tasks as i see it:
> * New tests for test suite (and update calcite-test-dataset to support Geode)
> * Add Integration tests that use calcite-test-dataset
> * Documentation



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


[jira] [Commented] (CALCITE-2059) Apache Geode adapter

2018-03-21 Thread Christian Tzolov (JIRA)

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

Christian Tzolov commented on CALCITE-2059:
---

[~vaquar.k...@gmail.com] check my answer on the stackoverflow thread. The 
adapter support Geode 1.3 (e.g. Gemfire 9.x) or newer.  Gemfire 8.2 is code 
incompatible. 

> Apache Geode adapter
> 
>
> Key: CALCITE-2059
> URL: https://issues.apache.org/jira/browse/CALCITE-2059
> Project: Calcite
>  Issue Type: New Feature
>  Components: geode
>Reporter: Christian Tzolov
>Assignee: Julian Hyde
>Priority: Major
> Fix For: 1.16.0
>
>
> I've been working on a Calcite adapter for [Apache 
> Geode|http://geode.apache.org]. 
> Current implementation uses the plain Geode API and 
> [OQL|http://geode.apache.org/docs/guide/13/developing/querying_basics/chapter_overview.html](Object
>  Query Interface) to push down relational expressions such as projections, 
> filtering, sorting, and grouping . 
> Provided functionality can hopefully address certain Geode use cases and will 
> provide a stepping stone for future improvements. 
> Here are some remaining tasks as i see it:
> * New tests for test suite (and update calcite-test-dataset to support Geode)
> * Add Integration tests that use calcite-test-dataset
> * Documentation



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


[jira] [Commented] (CALCITE-2059) Apache Geode adapter

2018-03-21 Thread vaquar khan (JIRA)

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

vaquar khan commented on CALCITE-2059:
--

I have added in stackoverflow , should i send in dev list ?

 

> Apache Geode adapter
> 
>
> Key: CALCITE-2059
> URL: https://issues.apache.org/jira/browse/CALCITE-2059
> Project: Calcite
>  Issue Type: New Feature
>  Components: geode
>Reporter: Christian Tzolov
>Assignee: Julian Hyde
>Priority: Major
> Fix For: 1.16.0
>
>
> I've been working on a Calcite adapter for [Apache 
> Geode|http://geode.apache.org]. 
> Current implementation uses the plain Geode API and 
> [OQL|http://geode.apache.org/docs/guide/13/developing/querying_basics/chapter_overview.html](Object
>  Query Interface) to push down relational expressions such as projections, 
> filtering, sorting, and grouping . 
> Provided functionality can hopefully address certain Geode use cases and will 
> provide a stepping stone for future improvements. 
> Here are some remaining tasks as i see it:
> * New tests for test suite (and update calcite-test-dataset to support Geode)
> * Add Integration tests that use calcite-test-dataset
> * Documentation



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


[jira] [Commented] (CALCITE-2059) Apache Geode adapter

2018-03-21 Thread Julian Hyde (JIRA)

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

Julian Hyde commented on CALCITE-2059:
--

[~vaquar.k...@gmail.com] We don't look at comments on closed cases. If you have 
a question please ask on the dev list.

> Apache Geode adapter
> 
>
> Key: CALCITE-2059
> URL: https://issues.apache.org/jira/browse/CALCITE-2059
> Project: Calcite
>  Issue Type: New Feature
>  Components: geode
>Reporter: Christian Tzolov
>Assignee: Julian Hyde
>Priority: Major
> Fix For: 1.16.0
>
>
> I've been working on a Calcite adapter for [Apache 
> Geode|http://geode.apache.org]. 
> Current implementation uses the plain Geode API and 
> [OQL|http://geode.apache.org/docs/guide/13/developing/querying_basics/chapter_overview.html](Object
>  Query Interface) to push down relational expressions such as projections, 
> filtering, sorting, and grouping . 
> Provided functionality can hopefully address certain Geode use cases and will 
> provide a stepping stone for future improvements. 
> Here are some remaining tasks as i see it:
> * New tests for test suite (and update calcite-test-dataset to support Geode)
> * Add Integration tests that use calcite-test-dataset
> * Documentation



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


[jira] [Commented] (CALCITE-2219) Avatica Connection/Statement/ResultSet don't throw if resource is closed

2018-03-21 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on CALCITE-2219:
-

Github user joshelser commented on the issue:

https://github.com/apache/calcite-avatica/pull/33
  
@laurentgo any chance I could request that you write a test case for one of 
this scenarios? Maybe the one in which lead you to find that this bug existed?
Otherwise, looks good to me too.


> Avatica Connection/Statement/ResultSet don't throw if resource is closed
> 
>
> Key: CALCITE-2219
> URL: https://issues.apache.org/jira/browse/CALCITE-2219
> Project: Calcite
>  Issue Type: Bug
>  Components: avatica
>Reporter: Laurent Goujon
>Assignee: Laurent Goujon
>Priority: Major
>
> According to JDBC spec/Javadoc, almost all methods of 
> {{Connection}}/{{Statement}}/{{PreparedStatement}}/{{ResultSet}} should throw 
> an exception if resource is closed.



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


[jira] [Commented] (CALCITE-2059) Apache Geode adapter

2018-03-21 Thread vaquar khan (JIRA)

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

vaquar khan commented on CALCITE-2059:
--

https://stackoverflow.com/questions/49411169/apache-calcite-geode-jdbc-adapte-not-working-with-jdbc

> Apache Geode adapter
> 
>
> Key: CALCITE-2059
> URL: https://issues.apache.org/jira/browse/CALCITE-2059
> Project: Calcite
>  Issue Type: New Feature
>  Components: geode
>Reporter: Christian Tzolov
>Assignee: Julian Hyde
>Priority: Major
> Fix For: 1.16.0
>
>
> I've been working on a Calcite adapter for [Apache 
> Geode|http://geode.apache.org]. 
> Current implementation uses the plain Geode API and 
> [OQL|http://geode.apache.org/docs/guide/13/developing/querying_basics/chapter_overview.html](Object
>  Query Interface) to push down relational expressions such as projections, 
> filtering, sorting, and grouping . 
> Provided functionality can hopefully address certain Geode use cases and will 
> provide a stepping stone for future improvements. 
> Here are some remaining tasks as i see it:
> * New tests for test suite (and update calcite-test-dataset to support Geode)
> * Add Integration tests that use calcite-test-dataset
> * Documentation



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


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

2018-03-21 Thread Eyal Segal (JIRA)

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

Eyal Segal commented on CALCITE-2211:
-

The  to the left is actually a "bigint(11)" column. The  is the 
"bigint(20) unsigned" that we're discussing.

Based on your CSV adapter, we didn't want to interfere with the type resolving. 
So JDBC resolves to BigInteger, and the type factory fails to resolve that to 
BIGINT.

In anyway our workaround was indeed to interfere with the resolving process, so 
when the code sees BigInteger we cast it to Long.

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



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