Thanks Andrey. Ideally Affinity must be used to find the node of an entry and for joins to reduce the data transfer between nodes. With the current implementation, group by queries of a cache (with no joins) on non affinity key will not work :( . Cout queries are also behaving in the same way. This is limiting usage of data grid feature. (this is just my view and may be wrong )
if i remember it correctly, Sergi said that Query 2 should work for one of previous questions. Thanks, Anil On 11 February 2017 at 22:39, Andrey Mashenkov <andrey.mashen...@gmail.com> wrote: > Hi Anil, > > Query 1 results looks ok. You got different results as affinity key is > equipmentId, but not serialnumber. > Query 2 has aggregates in subquery that is not supported yet [1]. > > [1] https://issues.apache.org/jira/browse/IGNITE-3860. > > > On Sat, Feb 11, 2017 at 7:18 PM, Anil <anilk...@gmail.com> wrote: > >> >> Hi team, >> >> i fee this is a bug. i have loaded cache with affinity key and group by >> queries on non affinity key returning results per node with both collocate >> = true/false. >> >> i have any created INSTALL_BASE cache with key as AffinityKey<String> and >> value is InstallBase pojo. and affinity key is equipmentId >> >> >> >> *Query 1 -* >> >> SELECT count (*) as count, serialnumber FROM InstallBase where >> serialnumber= '0000031438' group by serialnumber= '0000031438' >> >> Results - on 4 node cluster >> *With collocated = true* : >> >> 1 - 0000031438 >> 3 - 0000031438 >> >> *With collocated = false* : >> >> 4 - 0000031438 >> >> *Query 2 -* >> >> Select ib.*, p.count from installbase ib join (SELECT serialnumber , >> count (*) as count FROM InstallBase group by serialnumber) p on >> ib.serialnumber = p.serialnumber and ib.serialnumber = '0000031438' >> >> *With collocated = true* : >> >> 1 - 0000031438 >> 3 - 0000031438 >> 3 - 0000031438 >> 3 - 0000031438 >> >> *With collocated = false* : >> >> 1 - 0000031438 >> 3 - 0000031438 >> 3 - 0000031438 >> 3 - 0000031438 >> >> >> I see similar behavior with count queries as well. >> >> i strongly feel this is not correct behavior. Group by query on non >> affinity field is very common usecase. please share your view on this. >> >> Thanks >> > > > > -- > Best regards, > Andrey V. Mashenkov >
