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

Konstantin Boudnik updated IGNITE-3933:
---------------------------------------
    Description: 
There is an issue with JDBC when trying to play with different types of caches 
using the same JDBC connection.

*Example 1 - using simple JDBC connection URL* 
jdbc:ignite:cfg://file:///my-ignite-client-config.xm

1) For *REPLICATED* caches SQL query like *select \* from my_replicated_cache* 
returns as many duplicates for each record as many nodes in an Ignite cluster. 
Same problem with *select count(\*) from my_replicated_cache* - it returns 
actual number of records multiplied by the number of Ignite nodes.

2) At the same time if traversing the cache using "for" loop and iterator, it 
returns exactly what's needed without any duplicates.


*Example 2 - specifying replicated or partitioned cache in JDBC connection URL* 
jdbc:ignite:cfg://cache=my_cache@file:///my-ignite-client-config.xm
 
1) If specifying *PARTITIONED* cache in JDBC URL - queries like *select * from 
my_replicated_cache* return duplicates
 
2) If specifying *REPLICATED* cache in JDBC URL - it doesn't return duplicates 
for the *select * from my_replicated_cache* query. At the same time it failed 
to execute simple queries like *select * from my_partitioned_cache* against 
*PARTITIONED* caches throwing this error:

*java.lang.RuntimeException: javax.cache.CacheException: Queries running on 
replicated cache should not contain JOINs with partitioned tables 
[rCache=product, pCache=order]*

The fact that it's not possible to combine *REPLICATED* and *PARTITIONED* 
caches in one SQL query (using one JDBC connection) looks not very good. 

Also the idea of specifying cache name (for *REPLICATED* cache) in the JDBC URL 
for optimization purposes doesn't look good. It's better to utilize rather wide 
used "hits" approach, to provide optimization hints inside SQL query. Otherwise 
it's not possible to use JDBC with analytical and UI tools to run ad-hock SQL 
queries.

  was:
There is an issue with JDBC when trying to play with different types of caches 
using the same JDBC connection.

*Example 1 - using simple JDBC connection URL* 
jdbc:ignite:cfg://file:///my-ignite-client-config.xm

1) For *REPLICATED* caches SQL query like *select \* from my_replicated_cache* 
returns as many duplicates for each record as many nodes in an Ignite cluster. 
Same problem with *select count(*) from my_replicated_cache* - it returns 
actual number of records multiplied by the number of Ignite nodes.

2) At the same time if traversing the cache using "for" loop and iterator, it 
returns exactly what's needed without any duplicates.


*Example 2 - specifying replicated or partitioned cache in JDBC connection URL* 
jdbc:ignite:cfg://cache=my_cache@file:///my-ignite-client-config.xm
 
1) If specifying *PARTITIONED* cache in JDBC URL - queries like *select * from 
my_replicated_cache* return duplicates
 
2) If specifying *REPLICATED* cache in JDBC URL - it doesn't return duplicates 
for the *select * from my_replicated_cache* query. At the same time it failed 
to execute simple queries like *select * from my_partitioned_cache* against 
*PARTITIONED* caches throwing this error:

*java.lang.RuntimeException: javax.cache.CacheException: Queries running on 
replicated cache should not contain JOINs with partitioned tables 
[rCache=product, pCache=order]*

The fact that it's not possible to combine *REPLICATED* and *PARTITIONED* 
caches in one SQL query (using one JDBC connection) looks not very good. 

Also the idea of specifying cache name (for *REPLICATED* cache) in the JDBC URL 
for optimization purposes doesn't look good. It's better to utilize rather wide 
used "hits" approach, to provide optimization hints inside SQL query. Otherwise 
it's not possible to use JDBC with analytical and UI tools to run ad-hock SQL 
queries.


> JDBC issue with Replicated & Partitioned caches
> -----------------------------------------------
>
>                 Key: IGNITE-3933
>                 URL: https://issues.apache.org/jira/browse/IGNITE-3933
>             Project: Ignite
>          Issue Type: Bug
>          Components: jdbc-driver, odbc, SQL
>    Affects Versions: 1.8
>            Reporter: Igor Rudyak
>            Priority: Critical
>
> There is an issue with JDBC when trying to play with different types of 
> caches using the same JDBC connection.
> *Example 1 - using simple JDBC connection URL* 
> jdbc:ignite:cfg://file:///my-ignite-client-config.xm
> 1) For *REPLICATED* caches SQL query like *select \* from 
> my_replicated_cache* returns as many duplicates for each record as many nodes 
> in an Ignite cluster. Same problem with *select count(\*) from 
> my_replicated_cache* - it returns actual number of records multiplied by the 
> number of Ignite nodes.
> 2) At the same time if traversing the cache using "for" loop and iterator, it 
> returns exactly what's needed without any duplicates.
> *Example 2 - specifying replicated or partitioned cache in JDBC connection 
> URL* jdbc:ignite:cfg://cache=my_cache@file:///my-ignite-client-config.xm
>  
> 1) If specifying *PARTITIONED* cache in JDBC URL - queries like *select * 
> from my_replicated_cache* return duplicates
>  
> 2) If specifying *REPLICATED* cache in JDBC URL - it doesn't return 
> duplicates for the *select * from my_replicated_cache* query. At the same 
> time it failed to execute simple queries like *select * from 
> my_partitioned_cache* against *PARTITIONED* caches throwing this error:
> *java.lang.RuntimeException: javax.cache.CacheException: Queries running on 
> replicated cache should not contain JOINs with partitioned tables 
> [rCache=product, pCache=order]*
> The fact that it's not possible to combine *REPLICATED* and *PARTITIONED* 
> caches in one SQL query (using one JDBC connection) looks not very good. 
> Also the idea of specifying cache name (for *REPLICATED* cache) in the JDBC 
> URL for optimization purposes doesn't look good. It's better to utilize 
> rather wide used "hits" approach, to provide optimization hints inside SQL 
> query. Otherwise it's not possible to use JDBC with analytical and UI tools 
> to run ad-hock SQL queries.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to