Description
Inspired by IGNITE-4334.
Suppose we have two caches, one partitioned and one replicated. The following operation fails:
ignite.cache("replicated").query(new SqlFieldsQuery("select _key, _val from \"partitioned\".SomeType")).getAll();
Exception is as follows:
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) ...
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.