[
https://issues.apache.org/jira/browse/IGNITE-3933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-3933:
------------------------------------
Component/s: (was: odbc)
> 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
> 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 "hints" 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.4.14#64029)
