Incomplete key retrieval

Client Libraries Python Client
1

Hi,

Using Python (2 or 3 doesn’t change anything), I unable to “get” the primary key which was used for “put”. I started to see the problem when I decided to scan a ‘set’ and found all primary-keys set to ‘None’. I initially thought it was my fault, but I managed to reproduce the problem with the “standard” Python example. Here is part of the code :

…

Records are addressable via a tuple of (namespace, set, key)

key = (‘test’, ‘demo’, ‘foo’)

try:

Write a record

client.put(key, { ‘name’: ‘John Doe’, ‘age’: 32 }) except Exception as e: import sys print(“error: {0}”.format(e), file=sys.stderr)

(key, metadata, record) = client.get(key) print(key, record)

The output looks like this :

(‘test’, ‘demo’, None, bytearray(b’\xf5~\xc1\x835\xf7\x10\x0c\x04X\xf8\xa6D\xbc\xbcvm\x93G\x1e’)) {‘age’: 32, ‘name’: ‘John Doe’}

As you can see, the returned primary-key is set to None, while it should be set to ‘foo’.

Did I miss something ?

2

Hi Daniel,

By default the key portion of the key tuple is not saved, because it would cost extra in storage space. The key write policy controls this behavior, and you can modify it when you call aerospike.Client.put. Look at the example provided in the doc for that method.

Once the key is stored with the record, it will show up in subsequent aerospike.Client.get, scan, and query operations.

3

Hi Ronen,

I tried to use ‘DIGEST’ key attributes, describes in : http://www.aerospike.com/docs/guide/policies.html, since it’s what’s recommended : “DIGEST—Calculate (on the client) and send the digest value of key to the server. We recommend using this mode of operation.”

However, it has no effect… Besides, while I perfectly understand the technical reason behind this strategy, I have the feeling that the documentation is not very clear about it. Like…

“Indexes (primary keys and secondary keys) are stored in DRAM for ultra-fast access”, found in http://www.aerospike.com/docs/architecture/

and “(Index Persistence) To maintain throughput, primary indexes are not committed to storage—only to RAM” in http://www.aerospike.com/docs/architecture/primary-index.html

Though, if it’s stored in DRAM, why is that I don’t have it with a client.get() I had the false impression that indexes could be accessed any way…

Anyway, it finally worked using the SEND policy, but I still don’t understand the subtle difference between DIGEST and SEND regarding key storage… besides the ‘digest’ itself.

Thank’s for your help

4

Sorry, I should have been more explicit. aerospike.KEY_DIGEST is the default (‘just the digest’) and aerospike.KEY_SEND is the optional alternative value, which means store the key along with the bin data.

In both the primary index and secondary index the metadata is stored in DRAM, regardless of what storage device you have for the data, but the key, like bins, are stored as data (not in the index).

Glad it’s working.