> Creating a compute job for each record would quickly get unmanageable and
> broadcast isn’t equivalent as it doesn’t take into account the possibility of
> partitions migrating during calculations.
Of course creating a compute job for each record is a waste of
resources. Even in current really
Right, it doesn’t need to be the same — exposing partitions in this manner is
weird — but I think we need to support bulk operations in some capacity.
Creating a compute job for each record would quickly get unmanageable and
broadcast isn’t equivalent as it doesn’t take into account the possibil
> In Ignite 2, for bulk operations there’s an affinityRun method that takes a
> partition as a parameter. I don’t see an equivalent here. Is one in the plan?
Ideally users don't need to know a partition for execution of
computation and the right tool for it is colocation. Method with
partitions w
In Ignite 2, for bulk operations there’s an affinityRun method that takes a
partition as a parameter. I don’t see an equivalent here. Is one in the plan?
Are other APIs like apply, async methods, map-reduce being considered in later
phases?
> On 15 May 2023, at 12:52, Andrey Gura wrote:
>
> H
Hi, Igniters!
Please take a look at the first phase of proposal for Apache ignite 3
Compute API: Simple remote job execution [1].
While most issues are already resolved due to simplicity of the proposal
any feedback and ideas will be really useful for the next phases.
Thanks!
[1]
https://cwiki.
