WritePolicy sendKey effect

Hi,

I recently changed my code and added sendKey=true so that while reading I can get my actual key.
The problem is I had stored about a million keys without sendKey=true and now I have added this feature.

So what will happen on client.put() now ? i.e on update of those events which were inserted without sendKey=true
Will there be any error while updating those records ?

Also, how does sendKey=true work in case on client.put(). I am looking for explanation in terms of cached keys and stored keys.

Thanks.

Hi Holmes

By default, the Aerospike server does not store keys, only the digest of the key.

There are 2 ways to store the original key:

  1. Store it in a Bin
  2. Configure the server to store the key (Any Edition)

I usually use a Bin - Because most of the time the key has some “data” in it, so I store that data in Bins so I can easily get it or query it.

Hi @helipilot50,

Yes , that is right. I basically used writePolicy.sendKey = true. Everything seems to be working correct. But we are getting data mismatch for a record sometimes. It suddenly dates to back to two three month old snapshot of it .
So I asked this particular question in the same context because the only thing I changed code-wise was enable this feature. I saw the java client side code and all seems good. I still haven’t looked at the server side code, as in what really the server does when sendKey is enabled. I was hoping to get response on that line (specifically server side).

P.S : I found this one more clean than using separate bin :slight_smile: but I think I will use separate bin for now.

Thanks.

Hi Holmes,

When writePolicy.sendKey is on, the key itself (as opposed to the RIPEME160 hashed 20 byte digest) is also sent over to the server, to be stored with the record. If the record already exists and does not have a key already, it will store the incoming key.

There is a bug fixed in the recent Java client, pertaining to sendKey calculation. Java Client Library Release Note | Download | Aerospike

Thanks.

Thanks @wchu ,

I saw the change recently and I think this miscalculation which resluted in AIOBE might have have been causing issues related to data mismatch.

Thanks for fixing it.