ignite-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Igor Rudyak (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (IGNITE-3933) JDBC issue with Replicated & Partitioned caches
Date Mon, 19 Sep 2016 20:39:22 GMT

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

Igor Rudyak 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)

Mime
View raw message