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 process. If we go with your approach not sure whether we can calculate all the related partitioned caches to be locked dynamically. Ofcourse you would be in a better position to comment on it but cant we introduce something in affinity api which can be set/read through each affinityCall/Run, and the affinity api can be used inside SQL api - just like the same way calculating partition id for a specific key or an finding an atomic reference. Thanks, Luqman On 21 Nov 2017 20:17, "Vladimir Ozerov" <[email protected]> wrote: 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 <[email protected]> wrote: > 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 well for example: > > 1. We can check the context variable in all the partitioned cache > operations. In department and employee example if an employee is accessed > without an affinityRun or affinityCall computation it should also log a > WARNING message or through an exception based on the cache configuration. > > 2. The user would be able to implement their own custom checks using it. > For > example, if we want to have some abstract level checks to restrict > developers to use specific functionality related to partitioned caches. > > Luqman > > > > -- > Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/ >
