Re: SQL on PARTITIONED vs REPLICATED cache

Got it, Denis. I think you are right. On Wed, Apr 12, 2017 at 2:20 PM, Denis Magda wrote: > Dmitriy, > > No, I think that Sergi supposed a type of cache which reference is used > for a query execution. In my example > > >> 2. Error-prone scenario -

Re: SQL on PARTITIONED vs REPLICATED cache

Dmitriy, No, I think that Sergi supposed a type of cache which reference is used for a query execution. In my example >> 2. Error-prone scenario - *replicatedCache*.query(“SELECT * FROM >> partitionedCache … JOIN replicatedCache …”); *replicatedCache* reference is used for the query execution

Re: SQL on PARTITIONED vs REPLICATED cache

Denis, I think that you meant selecting from replicated cache first as an invalid scenario, but provided the wrong example. Here is the correct example for the invalid query: SELECT * FROM replicatedCache … JOIN partitionedCache …” I do agree, we should make the change, as long as we keep the

Re: SQL on PARTITIONED vs REPLICATED cache

Sergi, As far as I understand you’re considering an example below: IgniteCache partitioneCache = ...; IgniteCache replicatedCache = …; 1. Valid scenario - *partitionedCache*.query(“SELECT * FROM partitionedCache … JOIN replicatedCache …”); 2. Error-prone scenario -

Re: SQL on PARTITIONED vs REPLICATED cache

Yes, it's reasonable. On Wed, Apr 12, 2017 at 3:23 PM, Sergi Vladykin wrote: > Good point, but I'm not sure. The difference is that on client node you > should not be able to enable isLocal, while isReplicatedOnly is perfectly > valid. What do you think? > > Sergi > >

Re: SQL on PARTITIONED vs REPLICATED cache

Good point, but I'm not sure. The difference is that on client node you should not be able to enable isLocal, while isReplicatedOnly is perfectly valid. What do you think? Sergi 2017-04-12 15:18 GMT+03:00 Andrey Mashenkov : > Sergi, > > Got it. > > Does query

Re: SQL on PARTITIONED vs REPLICATED cache

Sergi, Got it. Does query execution way and results will be same for isReplicatedOnly flag and for isLocal flag turned on? If my understanding is correct, we will get same results and there is no need to introduce a new flag. On Wed, Apr 12, 2017 at 2:54 PM, Sergi Vladykin

Re: SQL on PARTITIONED vs REPLICATED cache

Ok, let it be an exception. I'm just saying that the thing does not work now. Sergi 2017-04-12 14:50 GMT+03:00 Andrey Mashenkov : > Sergi, > > I wounder how it is possible? > > Looks like it is impossible to run query on replicated cache, but select > data from a >

Re: SQL on PARTITIONED vs REPLICATED cache

Sergi, I wounder how it is possible? Looks like it is impossible to run query on replicated cache, but select data from a partitioned table. It will result with IlleagalStateException on stable topology or IgniteCacheException on unstable topology. See ReduceQueryExecutor.stableDataNodes() and

Re: SQL on PARTITIONED vs REPLICATED cache

Andrey, Because if you run query on replicated cache, but select data from a partitioned table, you will get only a part of the result. Igor, You are mostly right, but 1. Performance characteristics may change. 2. Ignite SQL processing pipeline may not support all the stuff in H2 SQL and fail

Re: SQL on PARTITIONED vs REPLICATED cache

Also, is it really a breaking change if the results are wrong? To me it looks more like a bugfix, i.e. you can't break something that does not work properly. Best Regards, Igor On Wed, Apr 12, 2017 at 2:04 PM, Andrey Mashenkov < andrey.mashen...@gmail.com> wrote: > Sergi, > > How can query to

Re: SQL on PARTITIONED vs REPLICATED cache

Sergi, How can query to replicated cache leads to to wrong results? Is it due to we can read backup entries? On Wed, Apr 12, 2017 at 12:31 PM, Sergi Vladykin wrote: > Guys, > > I want to introduce another breaking change for 2.0. > > Currently SQL is being processed

SQL on PARTITIONED vs REPLICATED cache

Guys, I want to introduce another breaking change for 2.0. Currently SQL is being processed differently when we call method `query` on partitioned cache and on replicated: on replicated cache we do not do any extra processing and execute the query as is on current node. This behavior