I am trying to fetch an entity based on an indexed field. Spring Data is actually able to retrieve the entity from Aerospike DB but unfortunately, it is not sending PK which results in the “message”: “Id must not be null!” error. I have enabled sendKey = true in readPolicy as well. Please find my configurations below ;
An update on this, when we marked KEY_SEND as true it worked for the new updated entities. Is there any way where can do this for all entities, we have around 2 crores users and it would be difficult for us to update all.
How does this work for queries on PK. It works perfectly fine without KEY_SEND being true.
Thanks for reaching out. Aerospike typically doesn’t store the primary key with each record because it uses a 20-byte digest as the primary key. This digest is a hash of (set name, key type, key) and has enough entropy that it can be considered unique.
When you’re reading via the primary key, Aerospike already has the actual key value – you supplied it in the call. So it will work fine. However, when you’re doing a query Aerospike does not have that key value available unless you supplied it with sendKey=true in the first place, so it cannot return it. This leads to the error you’re seeing.
Unfortunately, as the key doesn’t exist in the database, there is no way Aerospike can automatically add it – there isn’t enough information for it to re-create the key. If you have the keys stored elsewhere it would be fairly simple to touch each record with sendKey set to true. If you can let me know if you have this information, and in what format, it would be fairly simple to write a program to update these in the background.
Thank you for your reply. Somehow, it is difficult for me to understand the PK logic when queried on PK and when queried on other bins. Why is it not mapping the digest to PK when queried on Aerospike via other bins? It is able to get the record but without PK. We have around 20 million data. We missed updating the write policy with sendKey as true.
Does this mean if we enable scan, the retrieval of the records would give the same error?
Any other workaround that you think can help us?
We store our unique identifier in PK only which is digest I believe, can we use digest to touch the records after update sendKey true. If yes, can you provide me the script?
You should be able to touch the record with the sendKey policy set to true but would need to pass in the Primary Key as part of the touch command if you need the PK to be stored.
As Meher mentioned, you would need to pass in the Primary Key for each record as part of the touch command. Do you have this available? If so in what format? If they’re in a CSV file or similar it’s possible to write a program to do this automatically for example.