ignite-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexander Paschenko (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (IGNITE-4338) Cross-schema SQL SELECT on partitioned cache fails for no good reason
Date Wed, 30 Nov 2016 09:57:04 GMT

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

Alexander Paschenko updated IGNITE-4338:
----------------------------------------
    Description: 
Inspired by IGNITE-4334.

Suppose we have two caches, one partitioned and one replicated. The following operation fails:

{code:java}
ignite.cache("replicated").query(new SqlFieldsQuery("select _key, _val from \"partitioned\".SomeType")).getAll();
{code}

Exception is as follows:

{noformat}
Exception in thread "main" javax.cache.CacheException: Queries running on replicated cache
should not contain JOINs with partitioned tables [rCache=replicated, pCache=partitioned]
	at org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.stableDataNodes(GridReduceQueryExecutor.java:432)
	at org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.query(GridReduceQueryExecutor.java:529)
	at org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing$5.iterator(IgniteH2Indexing.java:1119)
	at org.apache.ignite.internal.processors.cache.QueryCursorImpl.iterator(QueryCursorImpl.java:98)
	at org.apache.ignite.internal.processors.cache.QueryCursorImpl.getAll(QueryCursorImpl.java:117)
	...
{noformat}

The reason is that during query analysis ({{org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing#queryTwoStep}})
we always deem leftmost cache (the one that the {{query}} method was called on) as participating
in the query which is clearly not true in the above example. Then we add to the query the
schema that it actually uses (it's the cache named *partitioned* in this case), and resulting
two-step query looks as if its SQL contained {{JOIN}} on *partitioned* and *replicated* caches
which we don't support for now.

Will consult Sergi about what to do next. According to Vlad, this should not affect the release
in any way and thus won't be fixed in 1.8.

  was:
Inspired by IGNITE-4334.

Suppose we have two caches, one partitioned and one replicated. The following operation fails:

{code:java}
ignite.cache("replicated").query(new SqlFieldsQuery("select _key, _val from \"partitioned\".SomeType")).getAll();
{code}

Exception is as follows:

{noformat}
Exception in thread "main" javax.cache.CacheException: Queries running on replicated cache
should not contain JOINs with partitioned tables [rCache=replicated, pCache=partitioned]
	at org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.stableDataNodes(GridReduceQueryExecutor.java:432)
	at org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.query(GridReduceQueryExecutor.java:529)
	at org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing$5.iterator(IgniteH2Indexing.java:1119)
	at org.apache.ignite.internal.processors.cache.QueryCursorImpl.iterator(QueryCursorImpl.java:98)
	at org.apache.ignite.internal.processors.cache.QueryCursorImpl.getAll(QueryCursorImpl.java:117)
	...
{noformat}

The reason is that during query analysis ({{org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing#queryTwoStep}})
we always deem leftmost cache (the one that the {{query}} method was called on) as participating
in the query which is clearly not true in the above example. Then we add to the query the
schema it actually used (it's the cache named *partitioned* in this case), and resulting two-step
query looks as if its SQL contained {{JOIN}} on *partitioned* and *replicated* caches which
we don't support for now.

Will consult Sergi about what to do next. According to Vlad, this should not affect the release
in any way and thus won't be fixed in 1.8.


> Cross-schema SQL SELECT on partitioned cache fails for no good reason
> ---------------------------------------------------------------------
>
>                 Key: IGNITE-4338
>                 URL: https://issues.apache.org/jira/browse/IGNITE-4338
>             Project: Ignite
>          Issue Type: Bug
>          Components: SQL
>    Affects Versions: 1.8
>            Reporter: Alexander Paschenko
>             Fix For: 2.0
>
>
> Inspired by IGNITE-4334.
> Suppose we have two caches, one partitioned and one replicated. The following operation
fails:
> {code:java}
> ignite.cache("replicated").query(new SqlFieldsQuery("select _key, _val from \"partitioned\".SomeType")).getAll();
> {code}
> Exception is as follows:
> {noformat}
> Exception in thread "main" javax.cache.CacheException: Queries running on replicated
cache should not contain JOINs with partitioned tables [rCache=replicated, pCache=partitioned]
> 	at org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.stableDataNodes(GridReduceQueryExecutor.java:432)
> 	at org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.query(GridReduceQueryExecutor.java:529)
> 	at org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing$5.iterator(IgniteH2Indexing.java:1119)
> 	at org.apache.ignite.internal.processors.cache.QueryCursorImpl.iterator(QueryCursorImpl.java:98)
> 	at org.apache.ignite.internal.processors.cache.QueryCursorImpl.getAll(QueryCursorImpl.java:117)
> 	...
> {noformat}
> The reason is that during query analysis ({{org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing#queryTwoStep}})
we always deem leftmost cache (the one that the {{query}} method was called on) as participating
in the query which is clearly not true in the above example. Then we add to the query the
schema that it actually uses (it's the cache named *partitioned* in this case), and resulting
two-step query looks as if its SQL contained {{JOIN}} on *partitioned* and *replicated* caches
which we don't support for now.
> Will consult Sergi about what to do next. According to Vlad, this should not affect the
release in any way and thus won't be fixed in 1.8.



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

Mime
View raw message