Hi there,
Working with SQL queries with setLocal(true) with partitioned cache, it is
very easy for someone to run SQL queries without affinityRun or affinityCall
computations which are the preferred ways of running queries on partition
cache, as described in [1].
Now what I was thinking whenever
Sounds like a good idea. Vladimir, would be nice to hear your thoughts.
D.
On Mon, Nov 20, 2017 at 7:45 AM, luqmanahmad wrote:
> Hi there,
>
> Working with SQL queries with setLocal(true) with partitioned cache, it is
> very easy for someone to run SQL queries without affinityRun or
> affinityC
Thanks dsetrakyan,
I would like to add a few more things over here which should be applicable
to partitioned caches.
This context variable which is set through affinityCall or affinityRun
should be available through either a helper class or cache configuration.
There could be other advantages as
Hi Luqman,
I do not think SQL and compute should be coupled in the product. Instead,
we should fix local query execution and pin partitions in the same way it
is done for affinityCall/Run and distributed SQL.
On Tue, Nov 21, 2017 at 6:25 PM, luqmanahmad wrote:
> Thanks dsetrakyan,
>
> I would l
Hi Vladmir,
Agree - they shouldnt be coupled togethor but what if we can set something
in affinity api which can be read in sql api.
Please correct me if I am wrong but in the affinityCall/Run we have to
provide all the cache names and rebalancing will skip if there is already
an operation in pro
Hi Luqman,
Required caches are already derived from SQL query through Ignite SQL
internals. We should just re-use this code for local queries. I filed a
ticket to fix this [1].
[1] https://issues.apache.org/jira/browse/IGNITE-7039
On Wed, Nov 22, 2017 at 12:05 AM, Luqman Ahmad
wrote:
> Hi Vlad
