findByIndexed fails "Id must not be null"

Hi Team,

Can anyone please help me on the below issue -

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 ;

@Configuration
public class AerospikeConfiguration extends AbstractAerospikeDataConfiguration {
 

   @Override
    public AerospikeDataSettings aerospikeDataSettings() {
        return AerospikeDataSettings.builder().sendKey(true).createIndexesOnStartup(true).build();
    }

    @Override
    protected ClientPolicy getClientPolicy() {
        ClientPolicy clientPolicy = super.getClientPolicy();
        clientPolicy.readPolicyDefault.sendKey = true;
        return clientPolicy;
    }
}

Fetching entity :

repo.findByIndexedField(value)

Further debugging I found that the below is the code which causes ‘Id must not be null’

MappingAerospikeReadConverter.java -

    private <T> T getIdValue(Key key, Map<String, Object> data, AerospikePersistentProperty property) {
        Value userKey = key.userKey;
        Object value = userKey == null ? data.get("PK") : userKey.getObject();
        Assert.notNull(value, "Id must not be null!");
        return this.convertIfNeeded(value, property.getType());
    }

Fetch entity doesn’t contain PK whereas when I fetch directly by ID, findById(), it works fine. Why is that it fails while using Indexed fields?

1 Like

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.

Hi Hetal,

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.

Hi Tim,

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.

Sure.

Can I get the command?

Hi Hetal,

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.

Thanks,

Tim

This topic was automatically closed 84 days after the last reply. New replies are no longer allowed.