Mailing-List: contact dev-help@ignite.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@ignite.apache.org
MIME-Version: 1.0
In-Reply-To: <CAGcMBHgRHk7zBZy27s+zjk36S8YJtEwLLKwQKDdCHjweeWbW4g@mail.gmail.com>
References: <CAGcMBHgRHk7zBZy27s+zjk36S8YJtEwLLKwQKDdCHjweeWbW4g@mail.gmail.com>
From: Dmitriy Setrakyan <dsetrakyan@apache.org>
Date: Mon, 21 Aug 2017 17:08:30 -0700
Message-ID: <CA+0=VoU8N2Er2yQnRGBdoCT4M=C=qPHmE+eHVX+kPx0Xknog7A@mail.gmail.com>
Subject: Re: Scan Queries: rows, updates and binary builders
To: dev@ignite.apache.org
Content-Type: multipart/alternative; boundary="001a1142a9529d484205574c67f5"

--001a1142a9529d484205574c67f5
Content-Type: text/plain; charset="UTF-8"

On Mon, Aug 21, 2017 at 9:01 AM, Yakov Zhdanov <yzhdanov@apache.org> wrote:

> Guys,
>
> I was asked how effectively change many rows in cache many times.
> Currently, this can done via ScanQuery - we send affinityCall(), inside
> callable we iterate over local primary cache partitions, filter entries by
> predicate and then do cache puts for rows that are wanted to change.
>
> I want to suggest more convenient API. Please share your thoughts.
>
> 1. Key Value pair in scan query is replaced with a single object IgniteRow
> which is basically a set of name-value pairs - the union of ones from key
> and value. If field names are not unique for a key-value pair then this
> pair is omitted with warning.
>

I am not sure what this would achieve. Can you explain why this is better
than the key-value API? Are you trying to avoid an extra cache lookup for
puts?


>
> 2. IgniteRow should be mutable. We can allow to change any field in the row
> and store results back to cache. If field belongs to cache key, then new
> key should be inserted and previous one removed. Optionally we can support
> throwing exception if key belongs to another node/partition after mutation.
>

Is this essentially the same as binary builder interface?


>
> 3. Such updates can be enlisted to ongoing transaction. For simplicity, let
> them be local transactions for the node we are running scan query on.
> However, I would not bother with this for now.
>

Makes sense.


>
> 4. I think it is inconvenient to convert binary object to builder, change
> field and serialize back to binary object. How about having BinaryObject
> replace(String fldName, Obj newVal)? If it is a simple replace then it can
> be done directly in the array or a copy of the initial array which seems to
> be times more efficient. Imagine we change an int field? Or a string to
> another string of the same length? This should also be applied to
> IgniteRow.
>

Will the replace operation return a builder, or another BinaryObject? Seems
a bit over-complicated to me. Are we trying to save on a few lines of code?


>
> --Yakov
>

--001a1142a9529d484205574c67f5--